< bitcoin-git>
bitcoin/master 6262182 practicalswift: Avoid use of low file descriptor ids (which may be in use) in FuzzedSock a...
< bitcoin-git>
bitcoin/master 9712f75 MarcoFalke: Merge #21677: fuzz: Avoid use of low file descriptor ids (which may be in ...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #21677: fuzz: Avoid use of low file descriptor ids (which may be in use) in FuzzedSock (master...avoid-open-fds-when-fuzzing) https://github.com/bitcoin/bitcoin/pull/21677
< bitcoin-git>
[bitcoin] hebasto closed pull request #21680: test: Use called_from_lib to point uninstrumented libs to TSan (master...210414-tsan) https://github.com/bitcoin/bitcoin/pull/21680
< aj>
MarcoFalke: have a seperate PR to backport both #21377 and #21686 for 0.21, i guess? looking for acks for #21614 now?
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21689: test: Remove intermittently failing and not very meaningful `BOOST_CHECK` in `cnetaddr_basic` (master...remove-intermittently-failing-and-largely-meaningless-ipv6-test) https://github.com/bitcoin/bitcoin/pull/21689
< provoostenator>
luke-jr: if you're still adament about a BIP 8 speedy trial, rebasing #21392 would seem more productive than reverting #21377
< provoostenator>
Because even if you loose that argument, the PR will be useful if we want future softforks to use (parts of) BIP 8.
< provoostenator>
Though there is the downside of not being able to burry BIP 9 forks as a whole for a while.
< bitcoin-git>
[bitcoin] jonatack opened pull request #21690: test: use higher value in cnetaddr_basic link-local test (master...cnetaddr-link-local-test) https://github.com/bitcoin/bitcoin/pull/21690
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21691: test: Check that no versionbits are re-used (master...2104-testVersionbits) https://github.com/bitcoin/bitcoin/pull/21691
< jnewbery>
We now have a client that can enforce taproot rules on mainnet. Huge thanks to everyone who helped us get here. Now lets put it in front of users :)
< robert_spigler>
Thank you everyone for all your hard work!
< hebasto>
wumpus: I cannot see any way how the `contrib/bitcoin-qt.pro` is used in the translation process, neither in the main repo nor in https://github.com/bitcoin-core/bitcoin-maintainer-tools. Besides it looks outdated and unmaintained. May I ask you to confirm/deny my assumption?
< wumpus>
hebasto: it is not used for anything, it exists to be able to edit the qt forms in qt designer nothing more
< wumpus>
i'm not sure if it is even *necessary* for that, but it is why it is there
< hebasto>
wumpus: thanks, qt designer does not need *.pro file at all
< hebasto>
maybe qt creator does
< wumpus>
feel free to create a PR to remove it, best way to find out if someone wants to keep it, you are right it hasn't been updated in a long time
< hebasto>
ok
< wumpus>
fwiw, the only question i get about it ever is why it exists
< hebasto>
it was in use with `qmake` years ago (what I found digging into the repo history)
< wumpus>
yes, that was the original reason, but when we switched to automake it was kept around for use w/ qt's GUI tools
< wumpus>
what it says there is definitely not true anymore
< hebasto>
I'll submit a pr
< wumpus>
thanks!
< bitcoin-git>
[bitcoin] hebasto opened pull request #21694: build: Use XLIFF file to provide more context to Transifex translators (master...210415-xliff) https://github.com/bitcoin/bitcoin/pull/21694
< bitcoin-git>
[bitcoin] hebasto opened pull request #21695: Remove no longer used contrib/bitcoin-qt.pro from the repo (master...210415-pro) https://github.com/bitcoin/bitcoin/pull/21695
< bitcoin-git>
[bitcoin] jonatack opened pull request #21696: DONOTMERGE test: drop cnetaddr link-local assert for macOS 10.14 to re-verify CI (master...cnetaddr-link-local-test-1) https://github.com/bitcoin/bitcoin/pull/21696
< bitcoin-git>
[bitcoin] jonatack opened pull request #21697: DONOTMERGE test: drop cnetaddr link-local assert for all CIs except macOS 10.14 (master...cnetaddr-link-local-test-2) https://github.com/bitcoin/bitcoin/pull/21697
< bitcoin-git>
[bitcoin] fanquake closed pull request #21697: DONOTMERGE test: drop cnetaddr link-local assert for all CIs except macOS 10.14 (master...cnetaddr-link-local-test-2) https://github.com/bitcoin/bitcoin/pull/21697
< jonatack>
fanquake: I was going to close after the CI results.
< fanquake>
why did you open two
< jonatack>
fanquake: they test different things. wasn't going to open any further ones. two is enough
< jonatack>
i guess it looked like a rampage hehe
< fanquake>
The diff is identical
< fanquake>
what are they testing differently?
< jonatack>
not identical, they are intended to re-verify that one assert passes only the macOS 10.14 CI and the other one passes all the other CIs but not the macOS 10.14 one
< fanquake>
I see. Can't this be tested in #21690 then?
< jonatack>
I used to run them on my own travis, but that is no longer. I've seen DONOTMERGE PRs done before to test CI results so I didn't think it was an issue.
< vasild>
why is it no longer?
< jonatack>
travis shut it down. are you using a paid travis account? (maybe i am missing something)
< vasild>
ah, yes, travis is no longer, but I have free cirrus account for open source and linked it to https://github.com/vasild/bitcoin
< vasild>
I think it operates as well as the cirrus hooked on the main repo, may be slower and have less concurrent jobs, but that is fine since I am the only one using it (occassionally)
< jonatack>
ah! good to know
< luke-jr>
provoostenator: MarcoFalke already blocked me from doing so; I have no reason to expect decent behaviour from devs strongarming BIP9 back in at this point anyway. Something is clearly going on behind the scenes.
< luke-jr>
provoostenator: after all, it had plenty of review and was RTM weeks before this BIP9 stuff, and still wasn't merged anyway
< michaelfolkson>
If you do can you provide a link to that discussion? Thanks
< luke-jr>
that ensures the height chosen is more stable on May 1st, and harder for miners to manipulate
< luke-jr>
ultimately BIP9 uses starttime to choose a height based on difficulty-period boundaries (2 weeks long)
< luke-jr>
it doesn't use the time directly
< michaelfolkson>
Ah gotcha, makes sense. Thanks
< MarcoFalke>
luke-jr: Not sure what you mean with "blocked". I am happy to reopen the pull I closed earlier today. I just think that it doesn't qualify for "high priority for review"
< luke-jr>
MarcoFalke: I mean I can't rebase it with it closed.
< luke-jr>
thanks. but I'm not sure there's any point if the BIP9-pushing group is going to prevent a merge
< luke-jr>
actually, this has LOT=True support and such too. Maybe it makes sense to close it anyway, and just reopen heights separately (when/if the issue of merging it gets resolved) :|
< michaelfolkson>
We already have a number of people on the BIP 9 PR saying it should be a new BIP rather than a revision of BIP 9. Obviously that is no guarantee (stranger things have happened) but I will NACK revising BIP 9
< vasild>
what an annoying deficiency in test/lint/lint-logs.sh
< michaelfolkson>
kallewoof: Yeah that will need to be revisited after this activation stuff has played out
< kallewoof>
michaelfolkson: I don't see the connection, but sure, as long as it's addressed.
< michaelfolkson>
kallewoof: At least for me (and I suspect for Luke too) activation has been eating time
< luke-jr>
kallewoof: maybe there should be a new BIP, also eliminating BIP Comments and adding Markdown back into the mix. certain people have decided to skip BIPs because they don't like people leaving comments, and I can only guess the Lightning BOLT stuff is because they prefer markdown…
< luke-jr>
but probably someone will need to talk to those groups to see if that resolves their complaints or not
< harding>
amiti: re your mailing list post, I know that in 2015 BRD wallet used addr messages to find nodes but I don't think it sent any messages. Obviously that was eons ago in Bitcoin time and I don't know what it does now.
< harding>
amiti: it's the only lightweight client I've ever heard of that used decentralized peer discovery.
< provoostenator>
I suspect most of the Lnd / Btcd based lightning wallets also use p2p to discover bitcoin peers.
< provoostenator>
Wallets like Breez (iOs) and Zap have an Lnd log export function too so you can see what it's doing.
< harding>
provoostenator: yeah, but if they're btcd based, they're full nodes, right? So they're probably advertising addrs. I think neutrino just uses the dns seeds (but I'm definitely not an expert).
< provoostenator>
They use client-side filtering (neutrino) so not really full nodes
< provoostenator>
I would guess, but better to check the logs, they use the DNS seeds to find nodes that support neutrino, since DNS seeds can filter those.
< harding>
Yeah, there was a discussion in here about a year ago between roasbeef and the operators of various seeds to get them to update their filter subdomains, so I assumed they used seeds. However, obviously using seeds doesn't preclude them also using decentralized peer discovery.
< provoostenator>
I have: dig -t A x49.seed.bitcoin.sprovoost.nl
< provoostenator>
Indeed, that should just be the first step.
< provoostenator>
In fact, at my seed doesn't have a node running.
< provoostenator>
Well I guess you could repeatedly beg a DNS seed for more peers.
< provoostenator>
luke-jr: the LOT=true was nowhere near RTM. The BIP 8 speedy trial PR by achow101 was much closer.
< provoostenator>
(I think you already concluded that yourself in a comment later today
< lightlike>
in that case, no problem for amiti's proposal
< harding>
lightlike: ah, if they send getaddr then they're maybe ok for amiti's proposed change.
< harding>
Yeah.
< Kiminuo>
Hi guys, a quick question: I have this PR https://github.com/bitcoin/bitcoin/pull/21244 and it got one ACK. Now, should I just wait patiently until somebody else will review the PR? Or am I supposed to do something else to increase the chance of merging it? I'm not in hurry. I would just like to understand the review process better.
< jeremyrubin>
Kiminuo: you can "review nag" people to take a look
< jeremyrubin>
if it gets > 2 ACKs it's possible for it to be merged
< Kiminuo>
jeremyrubin, should I do it here on IRC or on Github? How impolite it is? :)
< jeremyrubin>
but there's limited bandwidth for review, especially from maintainers, so you're waiting for a megre access contrib to review it as well
< Kiminuo>
yeah, I see
< jeremyrubin>
Kiminuo: it's not too impolite, but often times it can be a little quid-pro-quo. E.g., you do some review for someone else and they review for you
< Kiminuo>
jeremyrubin, I have actually tried that a bit as that seems friendly to me
< Kiminuo>
(not too much, just a bit)
< jeremyrubin>
It's also (no offense) a low priority PR since it has no external effect on users
< jeremyrubin>
e.g., pure refactor
< jeremyrubin>
right now reviewers are completely focused on preparing the RC1 for taproot
< jeremyrubin>
(most likely)
< jeremyrubin>
So figuring out which PRs must be bundled with that
< Kiminuo>
jeremyrubin, Yes, that's true. I kind of like small improvements as it opens doors for the true heroes :)
< jeremyrubin>
Yep -- and these things can be great
< jeremyrubin>
My advice to newer contributors is to think about momentum v.s. velocity
< jeremyrubin>
momentum is mass * velocity
< amiti>
harding, provoostenator, lightlike: thanks!! that's super helpful feedback. glad to see BRD would not be negatively impacted, I'll take a closer look at the others mentioned.
< jeremyrubin>
so to get more momentum, you can either try to increase core velocity or increase your mass
< jeremyrubin>
You can't really do much to improve velocity (other than helping review others code ofc)
< jeremyrubin>
But for momentum... just work on more stuff!
< jrawsthorne>
I also had the same question. I'm looking for reviewers for #21158. Would be important for alternative clients wanting to use core for taproot validation. Will see if there's any review I can help with
< Kiminuo>
So I kind of work as expected. That's good news. I'll try to put some effort into those reviews.
< provoostenator>
luke-jr: at most 1 ACK from someone with relevant expertise in this code, plenty of critical feedback from people who DO have that expertise
< jeremyrubin>
Kiminuo: MHM -- the feerate histogram sounds like a great feature!
< jeremyrubin>
Does clang dislike .cpp defined local templates?
< provoostenator>
Even aj who wrote several of the commits hasn't ACK'd it.
< Kiminuo>
:)
< michaelfolkson>
provoostenator luke-jr: I said at the time and I'll say again those ACKs were from inexperienced reviewers such as myself. So it wasn't ready for merge imo. But after the aj Andrew competing PRs I'm not exactly sure what aj will ACK anymore
< wumpus>
anyone have suggestions of something to add/remove or that is ready for merge?
< gleb>
I was thinking whether to put #21515 in high-prio at this point. The code is pretty much ready from my side (although ariard promised to contribute fuzzing), but at the same time we probably need to merge minisketch first separately
< achow101>
For context, the CA/B forum changed the requirements for organization validation for code signing certificates. So we need to register the association with government authority in order to get a certificate issued.
< jonasschnelli>
The Bitcoin Association Switzerland is now helping me to set this up...
< sipa>
What is CA/B ?
< achow101>
Certificate Authority / Browser forum
< jonasschnelli>
but since gov is necesarry for that part,..it might take awhile
< achow101>
that's the group that sets the rules for CAs and other related things
< sipa>
jonasschnelli: it's swiss government, aren't they super fast :)
< jonasschnelli>
no in everything. :)
< jonasschnelli>
*not
< sipa>
ok, what's a realistic timeline?
< jonasschnelli>
I don't have an estimate... and without the proper registration, we won't get new window certificates
< jonasschnelli>
(unsure about mac)
< jonasschnelli>
As soon as the lawyer take on the job, I think i can get an est.
< achow101>
I expect Apple will now have similar requirements as they must adhere to the same rules to remain a CA
< jonasschnelli>
probably 2-3 month,
< jonasschnelli>
achow101: very likely
< sipa>
could we try to do this in another jurisdiction?
< sipa>
where it's faster
< achow101>
An alternative I am beginning to explore now is to setup a LLC in the US, But I am not sure if that will be any faster
< jonasschnelli>
maybe it is also 3-4 weeks... as said. Just a wild guess right now
< BlueMatt>
achow101: you should be able to get an LLC in most states in a few days, max
< BlueMatt>
I know new york is like well under a week, maybe 1 biz day
< jonasschnelli>
a US LLC would be an option.
< achow101>
There are additional requirements for newly created organizations too...
< roconnor>
how about buying a shelf company. :D
< jonasschnelli>
If we want, we could do both (as sort of a redundancy)
< sipa>
a shelf company or a shell company?
< provoostenator>
A SPAC?
< sipa>
i like switzerland as a jurisdiction though, for things like this
< jonasschnelli>
me 2
< provoostenator>
We could raise billions for the certificate in the current market climate :-)
< jonasschnelli>
I can probably give an update on the est in a few days
< sipa>
this is currently a problem for signing new windows binaries, right?
< achow101>
yes
< sipa>
and we expect it will be a problem for apple binaries too in the near future?
< jonasschnelli>
Things that hit the company registry, often take a few weeks (AFAIK). Because ,... hm... its a gov database. :)
< achow101>
well if there are current PRs that we should have for 0.21.1, please tag them as such
< roconnor>
Apparently Companies Incorporated will sell Wolf and Associates LLC from Marshall Islands for $4809.
< achow101>
I don't think a shelf company would be the way to go
< roconnor>
Though if we have to sign binaries with that name, that will be confusing...
< jonatack>
just updated the description in the PR I mentioned...peers with the download net permission flag are incorrectly not being added to local addresses because they are mistakenly seen as noban peers
< achow101>
seems kinda sketchy
< roconnor>
I mean, they are for people who want "to save the time involved in taking the steps to create a new corporation."
< roconnor>
which tends to be for sketch organizations. But we want it for good purposes. :D
< jonatack>
achow101: agree
< roconnor>
That said, Wikipedia also claims "In Australia, a new company can get registered within 10 minutes."
< roconnor>
but achow101 mention something about restrictions regarding certificates for newly formed corporations.
< achow101>
A new LLC would run into "If the Subject’s or Subject’s Affiliate’s, Parent Company’s, or Subsidiary Company’sdate of formation, as indicated by either a QIIS or QGIS, was less than three years prior to the date of the Certificate Request, verify the identity of the Certificate Requester"
< sipsorcery>
dunno if it's of any use but Nicolas Dorier was/is involved in a Swiss company.
< achow101>
but I don't know if that would be a significant issue
< sipsorcery>
he'd probably be able to offer advice if needed
< sipsorcery>
maybe it would even help with the costs given it's a bitcoin company...
< roconnor>
oh, that doesn't sound like that big of a hurdle if I'm reading that correctly.
< achow101>
probably
< aj>
gleb: (could spin up a dedicated signet for erlay pretty easily, but either way would need something to fake txs on it -- that could just be something that generates txs to send to itself on a poisson timer though?)