jdmark has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
Livestradamus has quit [Quit: ~Peace~]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
jarthur has quit [Quit: jarthur]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
yanmaani1 has quit [Ping timeout: 255 seconds]
AmishBTC has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
AmishBTC has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
yanmaani1 has joined #bitcoin-core-dev
hsmiths1 has joined #bitcoin-core-dev
hsmiths has quit [Ping timeout: 248 seconds]
hsmiths1 is now known as hsmiths
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
AmishBTC has quit [Ping timeout: 276 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
jarthur has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
onetwo3 has quit [Ping timeout: 248 seconds]
onetwo3 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
nanotube has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
bitdex has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
sipsorcery_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
puchka has quit [Ping timeout: 248 seconds]
Guyver2 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
puchka has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
<bitcoin-git>
[bitcoin] ekzyis opened pull request #27232: Use string interpolation for default value of -listen (master...use-string-interpolation-for-default-value-of-listen) https://github.com/bitcoin/bitcoin/pull/27232
Guyver2 has left #bitcoin-core-dev [Closing Window]
Mercury has quit [Remote host closed the connection]
goatpig_ has joined #bitcoin-core-dev
goatpig has quit [Ping timeout: 252 seconds]
sipsorcery has joined #bitcoin-core-dev
sipsorcery_ has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
<achow101>
#proposedmeetingtopic host website using GitHub pages or similar
<vasild>
amiti_: lightlike: addrman Select() can decide to randomly skip the address even if it has found it after a "long" search. In the benchmark from #27214 I observe that sometimes it can visit 3k (bucket,pos) before returning the address and sometimes it can visit 180k (bucket,pos)
<achow101>
#proposedmeetingtopic host release binaries using GitHub releases
<vasild>
this makes it challenging to benchmark (and get meaningful results)
<lightlike>
vasild: it works in a probabilistic way: it starts at a random bucket/position, then cycles through the rest of that bucket deterministically. But if it hasn't found anything, it will pick the next bucket at random again and do the same thing - so there is no "skipping" because the buckets aren't processed in a deterministic order.
<vasild>
(the theoretical maximum size of addrman is 80k)
<vasild>
lightlike: that too, but I am talking about this skipping:
<vasild>
it is definitely a waste of resources if it visits the same bucket again, but this is a separate topic/issue
<vasild>
anyway, my point is that benchmarking this is like benchmarking "sleep(random())"
<vasild>
and yet, I want to see how much slower is the new code ;-X
<lightlike>
shouldn't taking many samples and building an average still work though?
hg has joined #bitcoin-core-dev
<lightlike>
If I remember correctly, the situation where we have just 1 address of a specific network in an otherwise full addrman and query for that network, was slower by a factor of ~5 compared to the situation where we have just 1 address in an otherwise empty addrman and do a normal Select(). We thought the reason for that was that in the first case we additionally need to make many lookups to existing address, just to find out that their
<lightlike>
network isn't the one we want.
martinus has quit [Quit: Leaving]
<vasild>
lightlike: you used the benchmarks from the PR?
martinus has joined #bitcoin-core-dev
<martinus>
When I configure with "./configure CXX=clang++ CC=clang --with-incompatible-bdb --enable-suppress-external-warnings" and then compile, I get a bunch of warnings due to the tracing macros, e.g. "validation.cpp:2379:5: warning: must specify at least one argument for '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]". Does anyone else get this, or is there a way I can disable these warnings?
<lightlike>
vasild: yes, I think so: AddrManSelectByNetwork covers the first situation (1 I2P, many IPV4), AddrManSelectFromAlmostEmpty the second one (1 IPv4, otherwise empty)
halo has joined #bitcoin-core-dev
<vasild>
"shouldn't taking many samples and building an average still work though?" -- probably yes, I had to change the bench to: bench.minEpochIterations(300).run(... to achieve that, without that the results vary too much to drive any conclusion
hg has quit [Ping timeout: 252 seconds]
bugs_ has joined #bitcoin-core-dev
<lightlike>
vasild: I didn't verify this yes, but are you sure that the other skipping is relevant to the bench tests at all? It's there to deprioritize selection of addresses that were tried recently or those that have failed attempts, but in the context of the bench tests I'd say neither of these should be the case: info.GetChance() should always return 1, and we should never skip addresses at this point.
<lightlike>
*yet
<vasild>
"are you sure that the other skipping is relevant" -- no ;)
<vasild>
you are right, chance is always 1, that is irrelevant
<amiti_>
oh!! great point about GetChance being 1 from the tests lightlike!
<amiti_>
"I had to change the bench to: bench.minEpochIterations(300).run" << yes makes sense, I was uncertain what the default config should be in the bench test, because I saw some of the "unstable results" on existing benches too.
<vasild>
martinus: that is on master? I do not get any warnings
<vasild>
martinus: as a workaround to sweep it under the carpet you can do: export NOWARN_CXXFLAGS="-Wno-gnu-zero-variadic-macro-arguments"
<martinus>
vasild: yes on master, I've been getting that warning for quite a while now
<vasild>
ENABLE_TRACING is not defined for me, this explains why I dont get any warnings, but CI should be running with -Werror and ENABLE_TRACING, no?
<martinus>
the warning comes in /usr/include/sys/sdt.h:281:9: note: macro '_SDT_ASM_BODY' defined here
<achow101>
#topic host website using GitHub pages or similar (achow101)
<achow101>
currently the website is hosted on a server administrated by someone who is no longer really involved in the project, and it occasionally stops working, requiring us to pester that person to fix it
puchka has quit [Ping timeout: 248 seconds]
<jamesob>
hi
<achow101>
since the site is basically just static pages, I think it would make sense for us to move its hosting to a static site host
<achow101>
one such possibility is github pages
<achow101>
any thoughts on this?
<hebasto>
content is static mostly, right?
<jamesob>
(for high-prio) I guess #24008 would be my request (now that the au.complete PR has been merged, thanks to all involved)
<pinheadmz>
is the site being hosted in a certain country or on certain equipment or anything special like that for any reason?
<lightlike>
if there are good alternatives, maybe it might makes sense to prefer one of those, so that if github should ever decide to kill the repo, at least the website would still be functional?
<jamesob>
so the risk, IIUC, of having Github host that is that that site hosts sensitive files like expected binary checksums. But I guess the alternative risk is that we have to sort of trust whoever else would be hosting that site. And those files should be checked against signatures anyway
<achow101>
pinheadmz: not that I'm aware of
<willcl_ark>
I did come across an issue related to SigStore recently which, if we moved to a more GitHub-based release process, could be worth integrating now that SigStore is up and running? https://github.com/bitcoin/bitcoin/issues/21524
<willcl_ark>
(to kind of act as a checksum against whatever is being hosted by GH)
<willcl_ark>
a cross reference, sorry
<achow101>
jamesob: but those are protected by signatures, so I don't think it particularly matters?
<jamesob>
I wonder if we could segment the general information on that site away from the even-maybe-sensitive file hosting; the former being easily hosted on GH
<jamesob>
Although maybe-sensitive stuff might be subtle, e.g. hyperlinks to download certain files
<jamesob>
but yeah in general achow101 I agree, everything should be checked against signatures anyway
<achow101>
I think that would be trivial by having a subdomain for the binaries
<jamesob>
yup
<pinheadmz>
where would we host the binaries?
<jamesob>
inscriptions ;)
<jamesob>
jkjk
<achow101>
that leads into the second (part of the) topic where I'm wondering whether we could switch to hosting the binaries on github itself?
<achow101>
since there is a releases page where release binaries can be uploaded
<kanzure>
having users trained to download and verify from another source might be better than hosting both code and releases on the same system
<jamesob>
I guess that seems as good a place as any; we could also encourage people to use torrents
<achow101>
the issue with release binaries currently is that only a few people can upload the binaries, and none of them are the current maintainers
<achow101>
lightlike: I think there are decent alternatives, but github pages is definitely the lowest barrier to entry
<sdaftuar>
achow101: can we give some of the current maintainers access to upload binaries to the current site?
<jamesob>
we could also link to alternative mirrors, like many linux distros do, hosted by well known individuals (a la DNS seeds)
<achow101>
having mirrors would be good in general
<jamesob>
I wonder if people who do the guix.sigs operation could optionally attach metadata declaring that they're hosting the binaries that they built... sounds maybe out of scope for this discussion though
<achow101>
sdaftuar: maybe, I think someone has asked but got a noncommital response? or it's kind of annoying to setup?
<achow101>
my understanding is that uploading binaries to the website is non-trivial process for whatever reason even though it seems like it shouldn't be that hard
<sdaftuar>
if it's annoying to setup i think it's by design, to minimize the attack surface for rogue binaries being distributed from the official site due to someone being hacked
<sdaftuar>
i would tend to think that having a secure site for distribution of our binaries makes sense? but given that the operational hassle falls on you and the other maintainers, it is tough or me to say what that process should be.
<jamesob>
one part of me is inclined to say "doesn't matter where you get it from, check the sigs" but the more pragmatic part of me knows that there are probably a lot of people who download and run without checking signatures
___nick___ has joined #bitcoin-core-dev
<sdaftuar>
yes i think that is undoubtedly the case
___nick___ has quit [Client Quit]
<pinheadmz>
in that case the *link* to download the binaries is also just as vulnerable
<pinheadmz>
i.e. if we host the website on GH we mine as well host binaries there too
<jonatack>
In general, it seems good to avoid increased integration with github (who likely want to increase project dependence on github by offering practical lock-in features) if anything else can be somewhat practical.
<sdaftuar>
pinheadmz: yes i think i'd be nervous about that
<achow101>
but also not hosting with github also raises other questions about who's owns the hosting and who's paying for it
<achow101>
that is currently an issue which I actually don't know the answer to
<jamesob>
achow101 right
___nick___ has joined #bitcoin-core-dev
<willcl_ark>
Would bitcoincore.org be fully deprecated (404) if we migrated?
<achow101>
willcl_ark: no, it would just be a dns change
<jonatack>
Seems not unimaginable for github to, for instance, be requested by govt agencies to disallow access to our binaries by people in certain locations
<willcl_ark>
OK great, was just wondering if both might co-exist for some time which could be confusing
<achow101>
jonatack: that would be a problem with any hosting provider, whether that's a service or a person
<darosior>
Would be good to know if there was a reason for having the website back when it was created, other than Github not being able to distribute binaries (or was it?)
<BlueMatt[m]>
<achow101> "that leads into the second (part..." <- I'd think that's a really bad idea - github is already a huge potential target, and we've seen dev accounts for such things compromised (not bitcoin specifically, but generally). I'd prefer we do multisig binary upload on our own hardware.
<BlueMatt[m]>
<achow101> "the issue with release binaries..." <- uhhh, i think its literally only one, we should change that tho!
<BlueMatt[m]>
the issue is the vast majority of people will just download the binary they find first and run it with no verificaiton
<lightlike>
achow101: sure, the thing is that if the website goes down, people could always use the repo as an alternative, and vice versa. If everything is in one place, likely both would be shut down at the same time.
<BlueMatt[m]>
so any mirror we add needs to be carefully considered to ensure we can secure it
<BlueMatt[m]>
given we now need to redo binary upload access with wladimir moving on, we should make it multisig like the rest of the website machine access is.
<achow101>
BlueMatt[m]: it's mildly annoying that we have to poke you in order to make some website changes, or when it goes kaput
<achow101>
afaik you are a required part of the multisig access currently?
<BlueMatt[m]>
we should update the access list tho
<BlueMatt[m]>
you dont, many others have access, its just that none of them can be bothered
<BlueMatt[m]>
well, many others have access all via multisig
<BlueMatt[m]>
nope
<BlueMatt[m]>
its 2-of-N
<BlueMatt[m]>
i think N is 5 but I'd have to check
<pinheadmz>
how does that work? multisig ssh ?!
<BlueMatt[m]>
yep!
<pinheadmz>
dope.
<BlueMatt[m]>
anyway, if y'all get an updated access list with yubikeys and ssh keys we can redo the access set and give an intro to how it works.
<pinheadmz>
how about the DNS / DNSSEC ?
<achow101>
BlueMatt[m]: cool, will chat on signal about that
<BlueMatt[m]>
what about it? yes, dnssec is on?
<pinheadmz>
how many people can change the A records ?
<pinheadmz>
are the dnssec keys held privately?
<BlueMatt[m]>
sg
<BlueMatt[m]>
I'll explain to the access list folks when we get there :)
<achow101>
if the current maintainers can get access to the existing infra, I guess the topic is moot?
<achow101>
anything else to discuss?
<jonatack>
I'm willing to do website content changes, if helpful. Was doing that for a few years for optech and the review club.
<BlueMatt[m]>
i mean we can revisit the infra, but probably best to first explain how it works on signal or so and then we can chat about if something else is better. I'm more than happy to build something better, but I'm not sure "github" is really that :/
<BlueMatt[m]>
jonatack: fwiw this is a separate access list, that's just the github repo with pgp sigs via the existing core maintainer tools.
<BlueMatt[m]>
the sigs are checked before going live
<achow101>
#endmeeting
<jonatack>
Seems like a good reminder to host a mirror of the binaries (and the git repo?), say, on tor/i2p/cjdns
<fanquake>
martinus: there is an issue open for what your are seeing, re warnings
<fanquake>
clang-16+
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
<andrew_mo_>
Do I have my timezone wrong?
<andrew_mo_>
yup I def do
Talkless has quit [Quit: Konversation terminated!]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
andrew_mo_ has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
halo is now known as hgst
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 276 seconds]
brunoerg has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 248 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
andrew_mo_ has quit [Ping timeout: 276 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
jamesob4 has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 255 seconds]
jarthur has joined #bitcoin-core-dev
jarthur_ has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
nanotube has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
bugs_ has quit [Quit: Leaving]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
chip__ has joined #bitcoin-core-dev
chip_x has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 276 seconds]
sipsorcery has quit [Ping timeout: 255 seconds]
sipsorcery_ has quit [Ping timeout: 255 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]