<bitcoin-git>
bitcoin/master b803229 John Moffett: Remove use of snprintf and simplify
<bitcoin-git>
bitcoin/master aff7546 MarcoFalke: Merge bitcoin/bitcoin#27036: test: Remove last uses of snprintf and simpli...
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #27036: test: Remove last uses of snprintf and simplify (master...2023_02_FixDBWrapperTest) https://github.com/bitcoin/bitcoin/pull/27036
<yancy>
sipa github does have an API for issues/PRs/etc so I guess those could be stored and managed elsewhere also. Maybe that's what Gitlab does, not really very familiar with Gitlab
Livestradamus has quit [Ping timeout: 260 seconds]
Livestradamus2 is now known as Livestradamus
Unhinged has joined #bitcoin-core-dev
Unhinged has quit [Client Quit]
<fjahr>
yancy: yes, the data is available via API and GL is using that to import it. It can also be stored somewhere else but then when the project is excluded from these platforms we would also ideally have a system that we can switch to quickly, that is still running, can't be stopped as easily and let's us continue development with relatively low friction. A self-hosted GL instance could give us that because it displays the PRs,
<fjahr>
issues and their discussions very similarly to GH and the conversations and development flows could continue in a similar fashion. CI integration is a similar issue but that will be even more tricky I think. If GH excludes us it's probably safe to assume that CircleCI might do the same.
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
buddy85 has joined #bitcoin-core-dev
buddy85 has quit [K-Lined]
dviola has quit [Ping timeout: 248 seconds]
AaronvanW has quit [Remote host closed the connection]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dviola has joined #bitcoin-core-dev
<phantomcircuit>
sipa: it does though, since if you get a true positive and a false positive the false positive isn't relevant, but is still part of your calculation
AaronvanW has joined #bitcoin-core-dev
<fanquake>
fjahr: What's the reason this data can't already be getting reviewed and tested prior to feature freeze?
<fanquake>
What counts as an "issue" during an rc?
<fanquake>
Not a fan of the idea of having to delay a relase for multiple weeks, because every couple days someone might pop up to say that the asmap file isn't quite correct (where, as far as I understand we don't know exactly what *correct* is?).
<fjahr>
fanquake: Right, I am explicitly trying to put together a process where the chance of a delay is minimized unless there is evidence of a substantial issue. It's the big reason I am also arguing against the "diffing logic" in my longer write-up because there we really lack an idea of how we can say diff x is ok and diff y is not ok. See also the last sentence in
<fjahr>
The reason we might not want to do it before feature freeze is that the routing table changes more and more over time and the fresher the data is, the better it should be for the users. Of course a few days don’t make a huge difference when compared to a 6 months release cycle, so I would be fine if a file is created a week before feature freeze for example. I am just trying to anchor the process to the steps we already
<fjahr>
have in place to make is explicit and this seemed like a good choice but happy to change it if there are better suggestions.
<fjahr>
An example of an issue that could be discovered is that a BGP hijack or leak occured around the time the file was created (something like https://www.kentik.com/blog/new-year-new-bgp-leaks/) and the route found it’s way into the asmap file that is chosen. A fix for this case could both be choosing another file that does not have the attack included or just removing the problematic line(s) from the file. Another issue
<fjahr>
could be that someone who runs their node on a specific IP looks up which AS their IP is mapped to in the file finds that the mapping is completely wrong. This case would probably require a bit of research (how did this happen, is this actually issue or is the users ISP is just not announcing prefixes themself etc.) and then rough consensus should decide if the file should be swapped.
<fjahr>
We will probably want to do a dry run of the process. Not sure if a dry run without an actual release gives us enough eyes though. Maybe for v25 we go through as many steps of the process but at the end we don’t ship the file in the binary. Instead we just say: ‘hey, this would have been the file we would have shipped, so it’s somewhat “official”. Please use it if you want to use asmap in your node.’
Guest88 has joined #bitcoin-core-dev
Guest88 has quit [Client Quit]
jespada has quit [Remote host closed the connection]
jespada has joined #bitcoin-core-dev
Guest39 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake closed pull request #25050: CValidationInterface: ValidationInterfaceUnregistering, called when being unregistered (master...validationIF_unregister) https://github.com/bitcoin/bitcoin/pull/25050
Guest39 has quit [Client Quit]
Guest39 has joined #bitcoin-core-dev
Guest39 has quit [Client Quit]
brunoerg has quit [Remote host closed the connection]
<pinheadmz>
vasild good idea, I need a maintainer to set up the webhook, achow101 helped me with core repo
<vasild>
pinheadmz: I guess that would be achow101 again
FrancisMr has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
earnestly has quit [Ping timeout: 260 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
aielima has joined #bitcoin-core-dev
FrancisMr has quit [Read error: Connection reset by peer]
FrancisMr has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
halosghost has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake closed pull request #21319: RPC/Blockchain: Optimise getblock for simple disk-hex case (master...getblock_optimise) https://github.com/bitcoin/bitcoin/pull/21319
<jonatack>
pinheadmz: nice! subscribed. perhaps an alternative to email notifications.
halosghost has quit [Ping timeout: 256 seconds]
AaronvanW has joined #bitcoin-core-dev
FrancisMr has quit [Ping timeout: 248 seconds]
Talkless has joined #bitcoin-core-dev
FrancisMr has joined #bitcoin-core-dev
halosghost has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 246 seconds]
AaronvanW has quit [Ping timeout: 252 seconds]
as2333 has joined #bitcoin-core-dev
FrancisMr has quit [Ping timeout: 246 seconds]
FrancisMr has joined #bitcoin-core-dev
martin_1 has joined #bitcoin-core-dev
pablomartin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] LarryRuane opened pull request #27052: test: rpc: add last block announcement time to getpeerinfo result (master...2023-02-getpeerinfo) https://github.com/bitcoin/bitcoin/pull/27052
pablomartin has quit [Remote host closed the connection]
pablomartin has joined #bitcoin-core-dev
dviola has quit [Quit: WeeChat 3.8]
FrancisMr has quit [Ping timeout: 248 seconds]
AaronvanW has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
halosghost has quit [Read error: Connection reset by peer]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
andrewtoth has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<bitcoin-git>
[bitcoin] pinheadmz opened pull request #27053: wallet: reuse change dest when re-creating TX with avoidpartialspends (master...change-addresses) https://github.com/bitcoin/bitcoin/pull/27053
b_101_ has joined #bitcoin-core-dev
hsmiths has quit [Quit: hsmiths]
b_101 has quit [Ping timeout: 268 seconds]
hsmiths has joined #bitcoin-core-dev
b_101_ has quit [Read error: Connection reset by peer]
b_101 has joined #bitcoin-core-dev
b_101_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 252 seconds]
AaronvanW has quit [Quit: Leaving...]
roze_paul has joined #bitcoin-core-dev
pablomartin has quit [Ping timeout: 260 seconds]
halosghost has quit [Read error: Connection reset by peer]
roze_paul has quit [Client Quit]
halosghost has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]