< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/773f8c1a7d56...7fcf53f7b452
< bitcoin-git> bitcoin/master 09b3e46 fanquake: doc: remove boostrap info from GUIX_COMMON_FLAGS doc
< bitcoin-git> bitcoin/master 7fcf53f fanquake: Merge #21672: doc: remove boostrap info from GUIX_COMMON_FLAGS doc
< bitcoin-git> [bitcoin] fanquake merged pull request #21672: doc: remove boostrap info from GUIX_COMMON_FLAGS doc (master...fixup_guix_options) https://github.com/bitcoin/bitcoin/pull/21672
< bitcoin-git> [bitcoin] fanquake pushed 10 commits to master: https://github.com/bitcoin/bitcoin/compare/7fcf53f7b452...2cd834e6c09d
< bitcoin-git> bitcoin/master 63879f0 Anthony Towns: tests: pull ComputeBlockVersion test into its own function
< bitcoin-git> bitcoin/master 5932744 Anthony Towns: tests: test ComputeBlockVersion for all deployments
< bitcoin-git> bitcoin/master 9e6b65f Anthony Towns: tests: clean up versionbits test
< bitcoin-git> [bitcoin] fanquake merged pull request #21377: Speedy trial support for versionbits (master...202103-bip9-speedy-trial-support) https://github.com/bitcoin/bitcoin/pull/21377
< luke-jr> fanquake: that was entirely inappropriate and violates community trust
< glozow> fanquake: 😘
< jeremyrubin> \o\
< jeremyrubin> \/o/
< Murch> fanquake: thanks
< jeremyrubin> release params next?
< BlueMatt> release params next.
< luke-jr> revert next.
< luke-jr> and/or revoke fanquake's access since he's abusing it
< harding> fanquake++
< BlueMatt> harding: I think you meant *= :)
< harding> :-)
< achow101> huzzah
< jeremyrubin> fanquake: thanks a LOT
< TallTim> clearly it should be decided by the price of DOGE
< TallTim> lolol
< TallTim> carry on.
< bitcoin-git> [bitcoin] achow101 opened pull request #21686: Speedy trial activation parameters for Taproot (master...taproot-mtp-st-params) https://github.com/bitcoin/bitcoin/pull/21686
< bitcoin-git> [bitcoin] am33r opened pull request #21687: 1IP per-connection policy (master...ameer_prevent_duplicate_connections_from_same_ip) https://github.com/bitcoin/bitcoin/pull/21687
< bitcoin-git> [bitcoin] jarolrod opened pull request #21688: doc: note on SDK for macOS depends cross-compile (master...depends-note-sdk) https://github.com/bitcoin/bitcoin/pull/21688
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #20558: test: Add MaybeCompactWalletDB tsan suppression (take 2) (master...2012-testSanTsan) https://github.com/bitcoin/bitcoin/pull/20558
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2cd834e6c09d...9712f75746e3
< 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?
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/21686 | Speedy trial activation parameters for Taproot by achow101 · Pull Request #21686 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/21614 | [0.21] test: Backports by MarcoFalke · Pull Request #21614 · bitcoin/bitcoin · GitHub
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< 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
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/9712f75746e3...a5e756b74e18
< bitcoin-git> bitcoin/master fa78590 MarcoFalke: test: Use mocktime to avoid intermittent failure
< bitcoin-git> bitcoin/master fa40d6a MarcoFalke: test: Reset mocktime in the common setup
< bitcoin-git> bitcoin/master a5e756b MarcoFalke: Merge #21676: test: Use mocktime to avoid intermittent failure in rpc_test...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21676: test: Use mocktime to avoid intermittent failure in rpc_tests (master...2104-testFixMocktime) https://github.com/bitcoin/bitcoin/pull/21676
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a5e756b74e18...7cb0bcb68110
< bitcoin-git> bitcoin/master f979b32 Andrew Chow: Add mainnet and testnet taproot activation params
< bitcoin-git> bitcoin/master 7cb0bcb MarcoFalke: Merge #21686: Speedy trial activation parameters for Taproot
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21686: Speedy trial activation parameters for Taproot (master...taproot-mtp-st-params) https://github.com/bitcoin/bitcoin/pull/21686
< jnewbery> \o/
< 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!
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/7cb0bcb68110...c6b30ccb2eee
< bitcoin-git> bitcoin/master 5198a02 Vasil Dimov: style: remove extra white space
< bitcoin-git> bitcoin/master 0c90ff1 Vasil Dimov: fuzz: set errno from FuzzedSock::Wait() if it simulates a failure
< bitcoin-git> bitcoin/master 9668e43 Vasil Dimov: fuzz: make FuzzedSock::Wait() sometimes simulate an occurred event
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21630: fuzz: split FuzzedSock interface and implementation (master...FuzzedSock_move) https://github.com/bitcoin/bitcoin/pull/21630
< 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?
< gribble> https://github.com/bitcoin/bitcoin/issues/21690 | test: use higher value in cnetaddr_basic link-local test by jonatack · Pull Request #21690 · bitcoin/bitcoin · GitHub
< fanquake> I don't see why we need 3 separate PRs.
< jonatack> this was the case last October. Before improving the documentation on the context, I wanted to re-verify to be sure it was still the case.
< jonatack> yes, sorry. can they just run and i'll re-close
< vasild> I am using my personal fork at https://github.com/vasild/bitcoin/pull/4/ for CI "experiments"
< 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> Anyone know the rationale for moving the start time a week earlier (April 24th) than Russell originally proposed (May 1st)? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html
< 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.
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573
< MarcoFalke> luke-jr: ^
< bitcoin-git> [bitcoin] vasild opened pull request #21700: net: expand Sock and fuzz-test more of CConnman (master...Sock_expand) https://github.com/bitcoin/bitcoin/pull/21700
< 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) :|
< bitcoin-git> [bitcoin] luke-jr closed pull request #19573: Replace unused BIP 9 logic with draft BIP 8 (master...bip8) https://github.com/bitcoin/bitcoin/pull/19573
< 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
< michaelfolkson> I also offered to work on a new BIP for Speedy Trial a month ago https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3668053
< vasild> All calls to LogPrintf() and LogPrint() should be terminated with \n ... LogPrint(BCLog::NET,
< kallewoof> speaking of revisions of BIPs, it would be splendid if https://github.com/bitcoin/bips/pull/1016 moved forward.
< 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
< kallewoof> luke-jr: You mean like https://github.com/bitcoin/bips/pull/1015 ? I don't have a preference personally.
< luke-jr> kallewoof: yeah, but addressing more than just the one issue you have
< kallewoof> luke-jr: the comments/markdown stuff? okay, first i heard. i'll look into that and update 1015.
< luke-jr> it's probably a can of worms ;.;
< kallewoof> luke-jr: I could use some excitement.
< luke-jr> O.o
< kallewoof> luke-jr: on a serious note, if you want help with the bip maintenance stuff, i'll gladly assist.
< achow101> #proposedmeetingtopic 0.21 backports and 0.21.1rc1
< bitcoin-git> [bitcoin] achow101 opened pull request #21701: [0.2] Speedy trial activation for Taproot (0.21...0.21-taproot-st) https://github.com/bitcoin/bitcoin/pull/21701
< bitcoin-git> [bitcoin] jonatack closed 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] JeremyRubin opened pull request #21702: Implement BIP-119 Validation (CheckTemplateVerify) (master...checktemplateverify-rebase-4-15-21) https://github.com/bitcoin/bitcoin/pull/21702
< 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> harding: BRD does indeed seem to participate in addr relay: By sending GETADDR and only accepting ADDRS after that: https://github.com/breadwallet/breadwallet-core/blob/develop/bitcoin/BRPeer.c#L283
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/21158 | lib: Add Taproot support to libconsensus by jrawsthorne · Pull Request #21158 · bitcoin/bitcoin · GitHub
< jeremyrubin> Many devs have tons of PRs open at once, and each one makes a little progress over time
< luke-jr> provoostenator: yes it was. 5 ACKs
< jeremyrubin> and once you have enough projects going on it keeps you pretty busy responding to feedback
< jeremyrubin> Of course you don't want to flood the repo with low priority work
< jeremyrubin> so I'd recommend picking up 1 more complicated project (e.g., glozow's testmempool package)
< jeremyrubin> and then having little things to work on in the meantime
< Kiminuo> jeremyrubin, That makes a lot of sense. I have this PR https://github.com/bitcoin/bitcoin/pull/21422 that I'm really after and https://github.com/bitcoin/bitcoin/pull/21244 is just a side hassle
< 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> Can anyone help me figure out what's up with https://github.com/bitcoin/bitcoin/pull/21702/checks?check_run_id=2355293832
< 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
< ariard> jrawsthorne: will review back #21158 :)
< gribble> https://github.com/bitcoin/bitcoin/issues/21158 | lib: Add Taproot support to libconsensus by jrawsthorne · Pull Request #21158 · bitcoin/bitcoin · GitHub
< provoostenator> Meeting?
< wumpus> #startmeeting
< provoostenator> hi
< hebasto> hi
< achow101> hi
< meshcollider> hi
< ariard> hi
< wumpus> hi
< michaelfolkson> hi
< wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< amiti> hi
< lightlike> hi
< jeremyrubin> hallo
< glozow> hi
< jnewbery> hi
< gleb> hi
< jonatack> hi
< wumpus> two porosed meeting topics (http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt) : short info/update on the "Bitcoin Core Code Signing Association" status. (jonasschnelli) 0.21 backports and 0.21.1rc1 (achow101)
< wumpus> any last minute topic suggestions?
< wumpus> #topic High priority for review
< jonasschnelli> hi
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 10 blockers, 2 chasing concept ACK right now
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/21515 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #21515 · bitcoin/bitcoin · GitHub
< gleb> For which I expected sipa would be here and say a word :)
< sipa> a word
< gleb> haha
< sipa> i can PR minisketch as a subtree if that's what people want
< wumpus> if it is blocked by something else i'm not sure it makes sense to add to blockers
< jonatack> #19521 seems ready
< gribble> https://github.com/bitcoin/bitcoin/issues/19521 | Coinstats Index by fjahr · Pull Request #19521 · bitcoin/bitcoin · GitHub
< sipa> i believe we're also going to do a review club on the c++ minisketch code; perhaps we want that first
< wumpus> jonatack: thanks, good to know
< gleb> sipa: is that scheduled?
< ariard> yeah let's PR minisketch first, will make erlay review easier
< glozow> +1
< wumpus> okay let's do that first then
< gleb> alright, then the plan is review club -> minisketch pr/review -> erlay pr review.
< wumpus> sgtm
< gleb> In the meanwhile people are welcome to start reviewing erlay 21515 :)
< ariard> erlay pr review can advance a bit, we should figure out testing on a signet :)
< sipa> gleb: jnewbery just ask me to do one on the 21st
< sipa> why signet?
< gleb> that's soon, great.
< provoostenator> Signet has a 1 byte mempool...
< provoostenator> Mainnet seems more interesting for erlay
< provoostenator> (for reckless devs)
< sipa> indeed
< ariard> oh can't generate a bigger mempool on the default signet
< lightlike> doesn't help much though if you are the only one running it on mainnet :-)
< provoostenator> Well signet is centralized so it could be made bigger
< gleb> I was running couple of my erlay nodes at mainnet a while ago, would do again.
< ariard> yeah but testing on mainnet you may not find other erlay peers?
< sipa> ariard: -connect is your friend :)
< gleb> sounds like something i should coordinate.
< ariard> sipa: ahah -connect is my friend but still need to find erlay friends
< ariard> something we can coordinate out of meeting for sure
< gleb> Perhaps by the next week meeting i can have a solid testing plan like that.
< jonatack> ariard: guess how we tested tor v3 and i2p ;)
< wumpus> i'm happy to help testing it fwiw
< gleb> alright, seems like we have an idea of how to proceed.
< wumpus> #topic Short info/update on the "Bitcoin Core Code Signing Association" status (jonasschnelli)
< sipa> paging jonasschnelli
< jonasschnelli> (have some lags)
< jonasschnelli> In order to obtain new certificates for code signing, we need to register the Bitcoin Core Code Signing Association in switzerland
< jonasschnelli> which requires some paperwork and yearly chores
< jonasschnelli> (like tax declaration, financial statements, etc.)
< 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> sipa: yes
< roconnor> but I probably shouldn't be commenting since i have no idea what I'm talking about.
< provoostenator> But yeah, all things equal - other than some delay - I'd rather see this thing in Switserland than in the US.
< jonasschnelli> I could try to extend the apple certificate and see what happens...
< wumpus> hopefully it doesn't get retroactively revoked too
< jonasschnelli> That would really surprise me.
< jonasschnelli> I think apple isn't that restrictive (as long as it is not malware)
< wumpus> okay, great
< jonasschnelli> conclusion: we are on it. No clear esta. I'll keep you updated.
< wumpus> thank you!
< sipa> okay
< sipa> sounds good
< wumpus> #topic 0.21 backports and 0.21.1rc1 (achow101)
< achow101> to meet the timeline discussed previously for taproot activation, we need to have 0.21.1rc1 in the next few days
< jeremyrubin> \o/
< achow101> the parameters have been merged into master, so all that's left is to do the backport
< achow101> and close out any remaining 0.21.1 backports
< jeremyrubin> achow101: also it's worth pointing out that backports are only required insofar as people want to signal via a backport client
< jeremyrubin> backports aren't blocking IMO for signaling, e.g. some miners use a recent core to gate old core patched mining nodes
< wumpus> isn't the backport the most important thing? at least the 0.21.x one
< achow101> considering that 22.0 probably won't land until after the timeout time, we need to have the backport
< wumpus> besides that softforks are never introduced in major versions
< provoostenator> n00b question, but signalling has to be done manually by miners anyway right? Or does getblocktemplate do that automagically?
< jeremyrubin> true, I just mean that the backports (given the minactivetime) can happen anytime before that height quite safely
< jeremyrubin> unless we think that miners will do signaling via backported clients
< jeremyrubin> But I agree we should get them out promptly, just that I don't perceive it as blocking
< jeremyrubin> but others can disagree with that assessment
< achow101> there are currently 5 things tagged for backport (or as backport) to 0.21.
< achow101> 3 are as backport, 2 are for backport
< harding> provoostenator: GBT does it automatically; I tested that was working as part of my review of 21377 (on regtest with vbparams).
< harding> provoostenator: but minres will probably do it manually anyway.
< provoostenator> Ah you're right, I do remember regtest signalling, just nevered inspected how that works.
< hebasto> wumpus: is it assumed to update translations for 0.21.1?
< jonatack> note bene, i'd suggest adding #21644 for backport, it fixes a bug in v0.21
< gribble> https://github.com/bitcoin/bitcoin/issues/21644 | p2p, bugfix: use NetPermissions::HasFlag() in CConnman::Bind() by jonatack · Pull Request #21644 · bitcoin/bitcoin · GitHub
< wumpus> hebasto: yes, unless there is a reason for skipping that?
< provoostenator> Anyway I would much miners to use the 0.21.1 release as soon as it comes out rather than "oh yeah, I'll remember to upgrade later".
< provoostenator> So not blocking, but we should not wait too long either.
< hebasto> wumpus: no reasons for skipping at all :) just want to restore wiped out Ukrainian translation
< jeremyrubin> provoostenator: +1 -- just note that the "later" is by minactivationheight
< wumpus> hebasto: makes sense!
< achow101> I think it would be reasonable to merge the current backports and leave the rest tagged for 0.21.1 for 0.21.2?
< wumpus> achow101: would agree, unless they are critical bugs of course
< wumpus> but we can definitely leave 'would be nice' stuff for 0.21.2
< sipa> makes sense
< provoostenator> There's a Boost dependency URL change PR, which should probably go in too
< provoostenator> #21662
< gribble> https://github.com/bitcoin/bitcoin/issues/21662 | build: update Boost download URL by fdoving · Pull Request #21662 · bitcoin/bitcoin · GitHub
< hebasto> ^ agree
< wumpus> any other topics?
< wumpus> #endmeeting
< 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?)
< jeremyrubin> BTW trying to debug https://github.com/bitcoin/bitcoin/runs/2355293835 still
< jeremyrubin> What is expected here?
< jeremyrubin> these identifiers are definitely present in this translation unit
< jeremyrubin> pet peeve: could we make all the build artifacts go into a hidden directory? cfields_?
< jeremyrubin> I think i fixed the ident issue, was the order of defns.
< jeremyrubin> err declarations