< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ea96e17e1f2c...5f18080c29c2
< bitcoin-git> bitcoin/master f22a3ec fanquake: build: make macOS HOST in download-osx generic
< bitcoin-git> bitcoin/master 5f18080 fanquake: Merge #21065: build: make macOS HOST in download-osx generic
< bitcoin-git> [bitcoin] fanquake merged pull request #21065: build: make macOS HOST in download-osx generic (master...correct_host_download_osx) https://github.com/bitcoin/bitcoin/pull/21065
< bitcoin-git> [bitcoin] fanquake opened pull request #21078: guix: only download sources for hosts being built (master...guix_selective_download) https://github.com/bitcoin/bitcoin/pull/21078
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5f18080c29c2...5a429d3d0fec
< bitcoin-git> bitcoin/master 51f3752 Ivan Metlushko: Add release notes for listdescriptors RPC
< bitcoin-git> bitcoin/master 5a429d3 MarcoFalke: Merge #21049: Add release notes for listdescriptors RPC
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21049: Add release notes for listdescriptors RPC (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21049
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/5a429d3d0fec...4e946ebcf111
< bitcoin-git> bitcoin/master fac05cc MarcoFalke: wallet: [refactor] Pass ArgsManager to WalletAppInit
< bitcoin-git> bitcoin/master fa06bce MarcoFalke: test: Add tests
< bitcoin-git> bitcoin/master 7777105 MarcoFalke: refactor: Move all command dependend checks to ExecuteWalletToolFunc
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20715: util: Add ArgsManager::GetCommand() and use it in bitcoin-wallet (master...2012-argsCmd) https://github.com/bitcoin/bitcoin/pull/20715
< wumpus> glozow: you just had the bad luck he latched on to your PR, we should probably have blocked him immediately after his attack on Randy
< wumpus> but I tend to give people the benefit of the doubt initially and didn't know about the history
< wumpus> it's disappointing that github still doesn't allow deleting inline comments
< fanquake> Yes. Can't even access the editing dropdowns for the comments by the deleted account
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4e946ebcf111...f1239b70d116
< bitcoin-git> bitcoin/master 20677ff Carl Dong: validation: Guard all chainstates with cs_main
< bitcoin-git> bitcoin/master f1239b7 MarcoFalke: Merge #21025: validation: Guard chainman chainstates with cs_main
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21025: validation: Guard chainman chainstates with cs_main (master...2021-01-chainman-activechainstate-locking) https://github.com/bitcoin/bitcoin/pull/21025
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/f1239b70d116...ea5a50f92a6f
< bitcoin-git> bitcoin/master 98892f3 Fabian Jahr: doc: Improve setup_clean_chain documentation
< bitcoin-git> bitcoin/master 590bda7 Fabian Jahr: scripted-diff: Remove setup_clean_chain if default is not changed
< bitcoin-git> bitcoin/master ea5a50f MarcoFalke: Merge #21042: doc, test: Improve setup_clean_chain documentation
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21042: doc, test: Improve setup_clean_chain documentation (master...scc-docs) https://github.com/bitcoin/bitcoin/pull/21042
< Kimi_> https://github.com/bitcoin/bitcoin/pull/21075#discussion_r570125634 - this comment made me think. Would .editorconfig (https://editorconfig.org/) be useful to avoid similar issues sooner?
< wumpus> Kimi_: maybe! hadn't heard of that yet
< Kimi_> wumpus, It's actually quite good. It's a simple file where you specify code style of your project. Like tabs vs spaces, indentation etc.
< Kimi_> It's supported by many editors & IDEs
< Kimi_> (MSVS, VSCode and many others)
< wumpus> yea having a standard shared between editors makes me much more enthousiastic about it than things that are specific to one environment
< aj> huh, that's cute
< wumpus> fanquake: also noticed that, weird
< aj> wumpus: looked into any of the decentralised bug-reports-in-git things? be kind-of neat to track PR reviews in git eventually
< wumpus> aj: i looked at radicle but it didn't seem ready yet, haven't looked any further
< aj> wumpus: there's https://github.com/MichaelMure/git-bug which seems a bit more ready; but it's just bugs -- doesn't seem like there's anything non-web for code review stuff
< wumpus> thanks, will take a look! yes, code review seems to be the most difficult thing to offer, even github's own command-line client doesn't do it yet (though the API can)
< wumpus> I mean, *inline code review*
< aj> yeah
< aj> i tried using the API to convert a text file to a review a while back, but it didn't work in confusing ways
< wumpus> I guess old mailing list based open source development had some advantage in that regard, at least it's semi decentralized (only needs some way to distribute messages all-to-all), that said, mail is broken and with the volume of changes it'd become insane
< wumpus> a replacement system really would need some UI and structured way to handle metadata
< wumpus> and also moderation, it sucks but we can't do without that
< wumpus> "works offline: in a plane or under the sea? Keep reading and writing bugs!" is nice, sure we can do this sort of by cloning bitcoin-gh-metadata but only in one way
< jnewbery> it's nice that we can export all the metadata into bitcoin-gh-metadata, but it's only moderately useful until there are other bug trackers/review platforms that can import it and reconstruct all of the cross-references.
< jnewbery> at least we have the export. If github gets so bad we can no longer usable, there's the possibility of reconstructing all the PR/review discussion
< jnewbery> *we can no longer use it
< wumpus> it's already useful for all kinds of local tooling/analysis, but yeah
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21080: fuzz: Configure check for main function (take 2) (master...2101-fuzzTake2) https://github.com/bitcoin/bitcoin/pull/21080
< jnewbery> agree about tooling/analysis. I use it to track review activity across the repo
< wumpus> someone could theoretically make a GUI or CLI on top of it to edit things (e.g. add reviews, comments, PRs, issues), which can submit back the changes, then it'd 'only' need some kind of bot to validate, merge and reconcile changes for the project metadata--then again i'd really prefer not to get into writing this kind of tooling myself and hope someone else will make something usable
< wumpus> it doen't seem terribly difficult but is a huge amount of work
< wumpus> i'd say git already handles a lot of the hard parts
< wumpus> i'm not convinced we need the full feature set of github, but something that handles only bugs is clearly not enough
< aj> year PR review seems to be github (and gitlab and other similar fully centralised web-based things) or email
< aj> year? yeah
< wumpus> yes
< aj> oh, i wonder if i could make the "p2p dashboard" thing a patch to https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/77
< wumpus> sure, more functionality is welcome
< bitcoin-git> [bitcoin] brunoerg opened pull request #21081: test, refactor: fix the unreachable code at feature_taproot (master...taproot-test-return) https://github.com/bitcoin/bitcoin/pull/21081
< jonatack> I wonder how different interaction would be, and if less moderation would be needed, without github's gamified activity graph and web browser "buttons to smash everywhere" UI...what if it was command line only...
< jonatack> nowadays that may sound like a luddite, but hey
< jonatack> (and the github notion of contributor list = commit list)
< wumpus> jonatack: i agree that Microsoft kind of went over the top with this, too much focus on as you say, easy buttons to smash everywhere... i think a lot of stupid spam could be avoided by adding just a little bit more friction
< wumpus> that said we also face persistent crazies with technical knowledge (e.g. zoltan yesterday) so i doubt it'd remove all need for moderation
< wumpus> and some kind of GUI is nice, i mean if people with less cli know-how like GUI designers and users can somehow interact with the repositories, at least to propose issues/PRs and comment, that's good
< wumpus> but for more advanced things such as merging, no UI is needed, we already use our own script after all
< wumpus> no need for a big green click-me button ๐Ÿ™‚ Iand don't get me started on the editing files through the website mis-feature
< wumpus> also i'd actually prefer to configure the settings for repositories through a configuration file instead of a web interface
< aj> hmm, how do you get the failure in #21039 to appear? on current master i just get the error, not assertion failure?
< gribble> https://github.com/bitcoin/bitcoin/issues/21039 | refactor: dont throw in GetChainName() by fanquake ยท Pull Request #21039 ยท bitcoin/bitcoin ยท GitHub
< aj> ah, you need includeconf= to trigger it i think
< fanquake> Don't think I've ever used includeconf=, so you shouldn't
< fanquake> just src/bitcoind -testnet -regtest
< aj> oh, maybe it's just when bitcoin.conf is entirely missing that you don't get the assert failure
< aj> yeah, looks like
< aj> wumpus: oh, apparently there's a thing called git-appraise! https://github.com/google/git-appraise eg https://git-appraise-web.appspot.com/static/review.html#?repo=23824c029398&review=de9ebcdf2a1e93365eefc2739f73f2c68a280c11
< MarcoFalke> aj: Nice finds. Keep them coming
< wumpus> aj: "Distributed Code Review For Git" neat!
< wumpus> it's a ... Google project?!
< aj> wumpus: in the sense it's explicitly not one, yeah? (or at least, git-appraise-web README has that disclaimer?)
< wumpus> (doesn't seem to rely on any google services to use it, just surprised it's under https://github.com/google/git-appraise)
< aj> yuck, both require signing google CLA
< wumpus> hhmm
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21082: refactor: Treat ArgsManager::Flags as uint32_t explicitly (master...2102-unsigned) https://github.com/bitcoin/bitcoin/pull/21082
< jnewbery> at the risk of trying to design a distributed git review system here, I don't think you want the review data to be in the same repo as the code. It should be some external system that references the git repo.
< MarcoFalke> PSA: All fuzz ci tests are failing due to a silent merge conflict in the integer sanitizer build
< MarcoFalke> #21082 might fix that
< gribble> https://github.com/bitcoin/bitcoin/issues/21082 | refactor: Treat ArgsManager::Flags as uint32_t explicitly by MarcoFalke ยท Pull Request #21082 ยท bitcoin/bitcoin ยท GitHub
< hebasto> in `feature_pruning.py` "This test takes 30 mins or more (up to 2 hours)" seems a bit outdated :)
< MarcoFalke> yeah, I think it was optimized a bit
< MarcoFalke> could remove that comment
< MarcoFalke> is it meeting time?
< jnewbery> yes
< achow101> meeting?
< wumpus> #startmeeting
< jonasschnelli> hi
< kanzure> hi
< achow101> hi
< jonasschnelli> (bot again down?)
< MarcoFalke> hi
< jonatack> hi
< michaelfolkson> hi
< fjahr> hi
< hebasto> hi
< rpite> hi
< meshcollider> hi
< warren> hi
< warren> hi
< wumpus> i did get a PM from the bot
< 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
< wumpus> doesn't look like there are any topics proposed in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt for this week
< wumpus> any last minute topics?
< warren> Is the TODO list of what needs to be written to release 0.22 with guix figured out?
< MarcoFalke> warren: dongcarl wanted to host a topic next week IIRC
< warren> k
< jamesob> hi
< aj> hi
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< MarcoFalke> Can I haz #20944?
< gribble> https://github.com/bitcoin/bitcoin/issues/20944 | rpc: Return total fee in getmempoolinfo by MarcoFalke ยท Pull Request #20944 ยท bitcoin/bitcoin ยท GitHub
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 8 blockers, 1 bugfix, 2 chasing concept ACK
< MarcoFalke> (it is blocking some fuzzers I wrote)
< wumpus> MarcoFalke: added
< achow101> #17331 for me
< gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 ยท Pull Request #17331 ยท bitcoin/bitcoin ยท GitHub
< wumpus> achow101: also added
< MarcoFalke> #20017 needs rebase, so can be removed for now?
< gribble> https://github.com/bitcoin/bitcoin/issues/20017 | rpc: Add RPCContext by promag ยท Pull Request #20017 ยท bitcoin/bitcoin ยท GitHub
< wumpus> 10 blockers again
< jamesob> Have a small fuzzer kink and a few comment updates on the highprio assumeutxo PR I'm going to address tonight
< jonatack> jonasschnelli: do you want to add #20962?
< gribble> https://github.com/bitcoin/bitcoin/issues/20962 | Alter the ChaCha20Poly1305@Bitcoin AEAD to the new specification by jonasschnelli ยท Pull Request #20962 ยท bitcoin/bitcoin ยท GitHub
< jonasschnelli> not for now
< wumpus> MarcoFalke: seems it's been needing rebase for two weeks
< MarcoFalke> jamesob: The fuzzer is a problem in master, I think
< jonasschnelli> I'd like to keep #15946
< jonatack> jonasschnelli: ok. i thought it might be the blocker for bip324 impl
< gribble> https://github.com/bitcoin/bitcoin/issues/15946 | Allow maintaining the blockfilterindex when using prune by jonasschnelli ยท Pull Request #15946 ยท bitcoin/bitcoin ยท GitHub
< wumpus> ping @promag
< jonasschnelli> jonatack: thanks. Need to finalize the BIP first
< promag> MarcoFalke: it has only 3 concept ack, not sure if itw worth rebasing
< sipa> can i have #bitcoin-core-dev #20861 ?
< sipa> eh
< gribble> https://github.com/bitcoin/bitcoin/issues/20861 | BIP 350: Implement Bech32m and use it for v1+ segwit addresses by sipa ยท Pull Request #20861 ยท bitcoin/bitcoin ยท GitHub
< wumpus> although it's for chasing concept ACK so i don't think it matters if it's rebased for concept ack
< jamesob> MarcoFalke: oh maybe in addition to this thing - I forgot to update fuzz based on a new lock annotation
< wumpus> only for blockers
< promag> wumpus: right
< MarcoFalke> Also #19716 doesn't pass gitian, so can be removed as well? (Maybe replace by #21036 because it is blocked on that)?
< gribble> https://github.com/bitcoin/bitcoin/issues/19716 | build: Qt 5.15.x by fanquake ยท Pull Request #19716 ยท bitcoin/bitcoin ยท GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/21036 | gitian: Bump descriptors to Focal for 22.0 by fanquake ยท Pull Request #21036 ยท bitcoin/bitcoin ยท GitHub
< wumpus> MarcoFalke: makes sense, done
< wumpus> any other topics?
< jonatack> #19145 has re-acks by provoostenator and I, seems close
< gribble> https://github.com/bitcoin/bitcoin/issues/19145 | Add hash_type MUHASH for gettxoutsetinfo by fjahr ยท Pull Request #19145 ยท bitcoin/bitcoin ยท GitHub
< MarcoFalke> topic: replace github?
< wumpus> jonatack: good to know, will have a look
< wumpus> #topic Replacing github
< core-meetingbot> topic: Replacing github
< jamesob> Oh boy
< wumpus> it's clear to me that this has to happen at some point but I don't think we found any projects ready for this
< jonasschnelli> didn't we had this topic recently?
< sipa> is there a concrete candidate to look at?
< wumpus> if there are, I'd suggest first setting up a parallel / mirror, so that people can try
< fjahr> It seems to be a constant topic since people get more and more frustrated
< wumpus> switching is not going to be a flag day thing
< MarcoFalke> sipa: Most of them seem "alpha" stage, so we'd have to play around with them
< luke-jr> was there a concrete problem with GitLab?
< dongcarl> Might this be an important enough thing that we should also look into building it ourselves / hacking existing open source solutions if none of the existing solutions work well enough?
< jamesob> I suspect that there will be even more frustration with an alternative. The big argument would be that github is a worrisome dependency to have
< wumpus> luke-jr: yes it's just another centralized thing
< promag> wont the alternative have other issues?
< aj> doing more tooling like gh-meta and ghwatch.py in the meantime seems like a good start?
< luke-jr> wumpus: eh, as opposed to what?
< jamesob> promag: right
< MarcoFalke> Funny, if GitHub had a simple moderator queue or other means of spam protection and a stable website, we probably wouln't be talking about this
< wumpus> aj: right, that's my idea
< fjahr> Maybe there should be a wiki page to collect promising projects, then people post there experiences with mirrors
< fjahr> Obviously this will be a long way
< wumpus> luke-jr: git-appraise, radicle, git-bug, and various other systems that use git for propagation instead of relying (entirely) on central hosted infrastructure
< jonasschnelli> aj: good point.
< jonasschnelli> We can enhance the UX with custom tools
< MarcoFalke> luke-jr: github and gitlab are hosted on the same infrastructure
< luke-jr> MarcoFalke: same?
< jamesob> We get a ton of utility out of the PR review flow; something that both has that and isn't centralized is going to be tough to find I think
< MarcoFalke> Though, it might be easier to build a two-way-mirror for review comments for gitlab
< wumpus> you can self-host gitlab or gitia etc but it'd be just another central server
< MarcoFalke> luke-jr: google cloud?
< wumpus> we need something that doesn't rely on a contributor to host something IMO
< aj> wumpus: there's also bugseverywhere fwiw https://bugs-everywhere.readthedocs.io/en/latest/tutorial.html
< wumpus> aj: ok definitely makes sense to keep track of these in a wiki
< wumpus> aj: this is too many for me to keep track of in my head :-)
< aj> wumpus: yeah, they're super hard to search for too
< aj> "git bug tracker"...
< fjahr> MarcoFalke: I don't think the infrastructure is causing the frustrations. Maybe the first question is: is the focus to fix usability issues with GH or to decentralize or we want to do both at the same time
< wumpus> I think we can do both at the same time
< wumpus> primarily it needs a sane way of doing code review that *doesn't* lose comments
< wumpus> this is the most serious issue with github, the collapsing comments and hidden diffs
< MarcoFalke> fjahr: the infrastructure is the cause for centralization (and the risk of getting shut down at any time). IIRC some countries can't access github
< fjahr> wumpus: maybe Gitlab doesn't lose comments, I don't know, but maybe that's a quick improvement on the usability front
< aj> MarcoFalke: they recently announced they'd opened back up to some of those countries iirc
< wumpus> fjahr: it's just not worth all the trouble of switching just to go to gitlab, you'll keep hopping
< MarcoFalke> aj: "some" ;)
< wumpus> aj: sure but who knows for how long the point is to not be dependent
< fjahr> MarcoFalke: agree, centralization is the same at GL but it might fix the losing comments issue which most recent frustrations seemed to come from
< jamesob> I'm guessing there'll be other unknown frustrations that pop up given GL isn't as actively developed as GH (AFAIK); and there is a pretty big cost to switching; CI integrations and drahtbot then need to be changed over
< jamesob> IMO we should be sure we want to move to whatever we move to
< luke-jr> (btw, disclosure: my web browsers have been compromised for months due to https://github.com/greatsuspender/thegreatsuspender/issues/1263 )
< MarcoFalke> proudly hosted by GitHub
< fjahr> lol
< dongcarl> lol
< luke-jr> XD
< wumpus> jamesob: I agree, if we switch it needs to be with something we have control over ourselves and plan to stick with for a long time
< aj> MarcoFalke: i'm sure they'll remain proud to host it while it implies there's no alternatives to github?
< MarcoFalke> aj: Typing as we speak
< aj> heh
< luke-jr> lol
< aj> MarcoFalke: (missed opportunity to write "typing as i type")
< wumpus> MarcoFalke: thanks!
< jnewbery> so were the meetings that fanquake/theuni/moneyball had with GH just a waste of time? They listened and then didn't actually fix anything that's important for us?
< wumpus> I think that concludes the topic for now, please look around if you find projects and try them out
< wumpus> jnewbery: I don't think it's a waste of time to discover what your requirements are, whoever implements them
< jnewbery> it's astonishing to me that one of the most important pieces of infrastructure for the open source community is owned by one of the most capitalized companies in the world and they can't even get a webpage to load
< luke-jr> eh, one with a long history of deceptive warfare against open source
< aj> jnewbery: i feel like you're overrating how competent humanity is at making computers work...
< wumpus> I mean, yes, they didn't really do much, but talking about things like that was probably constructive anyway
< promag> jnewbery: hold on, we have dark theme
< jnewbery> wumpus: I'm not suggesting that they shouldn't have tried (and I'm very grateful that they did!), but github don't seem to have done anything about the problems.
< michaelfolkson> It is Big Corp syndrome. Post acquisition the magic dies
< wumpus> jnewbery: agree on that
< jonasschnelli> didn't we had a direct contact with GitHub for a while?
< jamesob> promag: lol
< * fjahr> notes dark theme as hard requirement
< MarcoFalke> jonasschnelli: fanquake does have direct contact but they ignore him pretty much
< jonasschnelli> MarcoFalke: build up pressure?
< MarcoFalke> (not judging them. They probably have paying clients)
< MarcoFalke> jonasschnelli: I don't think open source is a priority for them
< sipa> fjahr: GH has a dark theme
< jonasschnelli> IMO GitHub has its flaws,.. but I don't see a better alternative and GH is certenly better than just tracking everything in a txt file
< wumpus> I was a paying client but stopped paying when they were taken over by Microsoft
< aj> #15847 #20227 #16472 #13411 might be useful
< gribble> https://github.com/bitcoin/bitcoin/issues/15847 | Feedback for GitHub CEO ยท Issue #15847 ยท bitcoin/bitcoin ยท GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20227 | Dependency on GitHub ยท Issue #20227 ยท bitcoin/bitcoin ยท GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16472 | Github started banning/restricting whole countries ยท Issue #16472 ยท bitcoin/bitcoin ยท GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13411 | Moving to self-hosted issue and patch management ยท Issue #13411 ยท bitcoin/bitcoin ยท GitHub
< jonasschnelli> thanks aj
< fjahr> sipa: yeah, just for the switching candidates ;)
< sipa> ha yes
< promag> I wonder how would gitlab behave with big prs with tens of comments and code
< sipa> "tens of comments"
< jonatack> I don't think GitHub is incentized to make the changes that we would like; I suspect maintaining a very uniform UX is key for GitHub, which might preclude per-repo configurable feature toggling and adjustable interaction friction
< sipa> there's literally dozens of us!
< promag> thousands
< sipa> i think this discussion should move to the wiki; there isn't much to do here expect looking for alternatives and evaluating them
< jonatack> GitHub's aim appears to be more faceBook than myspace in UX standardization
< promag> their api probably returns everything no?
< sipa> and getting back to the topic in a meeting in a few weeks maybe
< jonasschnelli> I suggest that moneyball take up the contact again (as of #15847)
< gribble> https://github.com/bitcoin/bitcoin/issues/15847 | Feedback for GitHub CEO ยท Issue #15847 ยท bitcoin/bitcoin ยท GitHub
< wumpus> sipa: agree
< jamesob> jonatack: *adds myspace to list of alternatives*
< jonatack> which would explain why even dark theme took so long for GitHub to agree to do
< fjahr> jonatack: I they would load comments as well as fb that would be great :D
< wumpus> any other topics?
< wumpus> #endmeeting
< 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
< core-meetingbot> Meeting ended Thu Feb 4 19:32:31 2021 UTC.
< michaelfolkson> Can I tentatively ask a question about Taproot activation? It appears to me there are three options for lockinontimeout
< michaelfolkson> Set to true in a Core release, set to false in a Core release or....
< michaelfolkson> Community consensus that a Core release will have false and this will be followed by another Core release in 6 months with true (if needed)
< michaelfolkson> Does that third option sound viable? Or would Core not want an instruction on what to do in 6 months?
< sdaftuar> i would personally not agree with a commitment to release a consensus change at any specific point in the future.
< michaelfolkson> Ok thanks, that's helpful sdaftuar
< michaelfolkson> I don't want to discuss the merits of true, false. Go to #taproot-activation for that...
< michaelfolkson> If anyone else has any thought on that let me know. Thanks
< michaelfolkson> On that third option specifically
< jonatack> fjahr: oh, agreed. i use gh pr now for reading review comments via the cli; as of v1.5 it shows all of the comments with one cli command and is far faster to use. just takes getting used to.
< fjahr> Yeah, thanks, I need to give it another chance
< sipa> sdaftuar: impressive, you have a 100% acceptance rate on your bitcoin SE answers
< sdaftuar> i strive for perfection
< sdaftuar> now if only my bip acceptance rate were so high... :)
< aj> sdaftuar: maybe you should game the system and post your bips on stackoverflow?
< luke-jr> sdaftuar: I can't suggest what to add to Motivation because I literally have no idea what the point is
< sipa> sdaftuar, luke-jr: the second paragraph of sdaftuar's ML post about it (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018340.html) is probably a good start
< luke-jr> ah
< luke-jr> so the point is to allow N*M light connections where being unsure means only N could be accepted?
< luke-jr> (though IIRC our limits are due to FD set sizes and open fd limits currently?)
< sipa> luke-jr: my understanding is this: we have a default inbound connection limit (125) which is based on the observation that every "fully fledged" connection has a significant impact on processing costs and bandwidth (among other things), so we can't just raise that without impacting worst-case performance of average nodes
< sipa> if we instead knew for block-only connections (on the incoming side) that they'd *never* need transactions, the worst part is reduced, and perhaps it becomes acceptable to have more incoming connections per peer, given that some percentage of them are reserved for non-block-relaying connections
< sipa> right now, the block-only nature of a connection is only known on the outbound side
< luke-jr> I see
< sdaftuar> sipa: thank you for translating