--- Log opened Thu Oct 27 00:00:59 2022 10:03 -!- gnusha [~gnusha@user/gnusha] has joined #bitcoin-core-dev 10:03 -!- Topic for #bitcoin-core-dev: 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 10:03 -!- Topic set by laanwj [] [Sat May 22 03:05:22 2021] 10:03 [Users #bitcoin-core-dev] 10:03 [@gribble ] [ darosior ] [ hsmiths ] [ lightningbot ] [ sanket_cell ] 10:03 [ [D] ] [ DeanGuss ] [ hugohn__ ] [ Lightsword ] [ schmidty_ ] 10:03 [ ___nick___ ] [ denise[m] ] [ infernix ] [ livestradamus ] [ sdaftuar1 ] 10:03 [ _aj_ ] [ dergoegge ] [ instagibbs ] [ lowhope ] [ sebx2a ] 10:03 [ _flood ] [ dermoth ] [ ishaanam[m] ] [ luke-jr ] [ sgiath ] 10:03 [ achow101 ] [ dhruv ] [ Jackielove4u ] [ MacroFake ] [ shiza ] 10:03 [ adiabat ] [ dlb76 ] [ jamesob ] [ MatrixBot123 ] [ sipa ] 10:03 [ ajonas ] [ dodo ] [ jarolrod ] [ mekster66949 ] [ sloorush ] 10:03 [ Alina-malina ] [ doppo ] [ jarthur ] [ meshcollider ] [ SpellChecker ] 10:03 [ amiti_ ] [ dougefish ] [ javi404 ] [ michaelfolkson] [ stacie ] 10:03 [ amovfx ] [ dviola ] [ jb55 ] [ midnight ] [ stevenroose ] 10:03 [ amovfx_ ] [ Earnestly ] [ jdmark ] [ mimmy ] [ stick ] 10:03 [ andytoshi ] [ elichai2 ] [ jeremyrubin ] [ mjdietzx__ ] [ stickies-v ] 10:03 [ Ara ] [ emzy ] [ jesseposner ] [ moneyball__ ] [ stratospher[m] ] 10:03 [ ariard ] [ EPiSKiNG- ] [ jetpack ] [ Murch ] [ sturles ] 10:03 [ arik ] [ erwanor_ ] [ jkczyz ] [ murrayn ] [ sugarpuff_ ] 10:03 [ arturomf94[m] ] [ euclid[m] ] [ jnewbery ] [ nanotube ] [ szkl ] 10:03 [ aureleoules ] [ Evel-Knievel ] [ johnzweng ] [ Nebraskka ] [ takinbo ] 10:03 [ b10c ] [ Evolver ] [ jonasschnelli] [ neha ] [ Talkless ] 10:03 [ baakeydo1 ] [ ExEric3 ] [ josibake____ ] [ notmandatory ] [ TallTim ] 10:03 [ bcdarc_ ] [ fanquake ] [ josie[m] ] [ otoburb ] [ TheCharlatan ] 10:03 [ berndj ] [ FelixWeis ] [ jrawsthorne ] [ outfox ] [ TheRec ] 10:03 [ bitcoin-git ] [ fjahr ] [ jrayhawk ] [ pablomartin_ ] [ theStack ] 10:03 [ BlueMatt[m] ] [ Flow ] [ justHaunted ] [ phantomcircuit] [ tinova4 ] 10:03 [ bomb-on ] [ furszy ] [ kakolainen[m]] [ pinheadmz ] [ tripleslash ] 10:03 [ brunoerg ] [ ghost43 ] [ kalle ] [ provoostenator] [ uasf_ ] 10:03 [ BUSY ] [ gleb071 ] [ kanzure ] [ qubenix ] [ upekkha ] 10:03 [ bw ] [ glozow ] [ katsu_ ] [ raj- ] [ vasild ] 10:03 [ cfields ] [ gnaf ] [ kcalvinalvin ] [ real_or_random] [ vincenzopalazzo] 10:03 [ cm ] [ gnusha ] [ kexkey ] [ realies ] [ w0xlt_ ] 10:03 [ cmirror ] [ GoldmanSats_ ] [ kinlo ] [ reardencode ] [ warren ] 10:03 [ cncr04s ] [ greypw2546002] [ koolazer ] [ roasbeef ] [ willcl_ark ] 10:03 [ cold ] [ gwillen ] [ kouloumos ] [ rockhouse ] [ windsok ] 10:03 [ core-meetingbot] [ halosghost ] [ kvaciral ] [ rodarmor ] [ x88x88x ] 10:03 [ cornfeedhobo ] [ harding ] [ laanwj ] [ RubenSomsen ] [ yakshaver ] 10:03 [ Cory ] [ hebasto ] [ landryl_ ] [ ryanofsky ] [ yanmaani2 ] 10:03 [ cotsuka ] [ helo ] [ LarryRuane ] [ S3RK ] [ Zenton ] 10:03 [ cryptapus ] [ hendi ] [ lbia ] [ sandipndev ] [ zeropoint ] 10:03 [ da2ce7 ] [ hirish_ ] [ lightlike ] [ sanket1729 ] 10:03 -!- Irssi: #bitcoin-core-dev: Total of 194 nicks [1 ops, 0 halfops, 0 voices, 193 normal] 10:03 -!- Channel #bitcoin-core-dev created Wed May 19 06:52:47 2021 10:04 -!- Talkless [~Talkless@mail.dargis.net] has quit [Ping timeout: 260 seconds] 10:06 -!- Irssi: Join to #bitcoin-core-dev was synced in 143 secs 10:06 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev 10:14 -!- Talkless [~Talkless@mail.dargis.net] has quit [Ping timeout: 250 seconds] 10:18 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bd478890c513...551c8e9526d2 10:18 < bitcoin-git> bitcoin/master eb679a7 w0xlt: rpc: make `address` field optional 10:18 < bitcoin-git> bitcoin/master 551c8e9 Andrew Chow: Merge bitcoin/bitcoin#26349: rpc: make `address` field optional `list{tran... 10:19 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev 10:34 -!- gnaf [~gnaf@212-129-37-129.rev.poneytelecom.eu] has quit [Quit: Konversation terminated!] 10:37 -!- nanotube [~nanotube@user/nanotube] has quit [Ping timeout: 246 seconds] 10:52 -!- NorrinRadd [~me@85.237.194.152] has joined #bitcoin-core-dev 10:58 < luke-jr> FWIW, I'm finding some of the arguments against full RBF to be semi-convincing - as reasons to leave the default off, but not to remove the option 10:59 < luke-jr> (note, not fully convincing :p) 11:00 < _aj_> luke-jr: hey, why does knots have a service bit for full rbf but no preferential peering? 11:01 < instagibbs> potentially preferentially non-peering to fullrbf? :) 11:01 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev 11:02 < _aj_> luke-jr: (or is it just "patches welcome" ?) 11:07 < luke-jr> _aj_: no particular reason; didn't seem important enough? 11:07 < _aj_> luke-jr: what's the point of the service bit without preferential peering? 11:07 < luke-jr> _aj_: and the code paths are such that I'd prefer to have anything in that area reviewed :x 11:08 < luke-jr> _aj_: so other nodes can preferentially peer 11:08 < _aj_> luke-jr: ah that's not quite "patches welcome" but near enough 11:08 < luke-jr> eg, petertodd used to maintain one 11:15 < lightlike> having the service bit also allows manual preferential peering via "addnode" 11:18 < luke-jr> lightlike: you could do that without a service bit tho? 11:18 < lightlike> but how would you know peers supporting full-rbf if they don't advertise that in their service bits? 11:21 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 246 seconds] 11:28 < sipa> lightlike: I'm not sure you should be using rumoured IP addresses as targets manual connection in the first place... it works of course, but manual connections are more intended for nodes for which you have out-of-band reasons to know. 11:32 < bitcoin-git> [bitcoin] achow101 closed pull request #26349: rpc: make `address` field optional `list{transactions, sinceblock}` response (master...issue_26338) https://github.com/bitcoin/bitcoin/pull/26349 11:32 < _aj_> sipa: the only thing is they don't get discouraged/disconnected for misbehaviour (weak form of noban) isn't it? 11:33 < sipa> Well and they get separate connection slots. 11:33 < sipa> With separate rules for deciding how they're used. 11:34 < _aj_> sipa: preferential peering would probably get extra connection slots too (and obviously have separate rules) though? 11:34 -!- NorrinRadd [~me@85.237.194.152] has quit [Quit: NorrinRadd] 11:36 < _aj_> sipa: (which maybe just reduces it to "i'm not sure you should do preferential peering, whether manual or automatic", i guess) 11:37 < sipa> Wait maybe we're talking about different things. 11:37 < sipa> I was just talking about the distinction between manual and automatic connections. 11:39 < lightlike> btw jonatack did a twitter poll about this recently - almost 50% of the respondents that used manual connections at all used them to connect to unknown peers: https://twitter.com/jonatack/status/1524377548062351360 11:39 < jonatack> Yes IIRC addnode connections have 8 separate slots in addition to the 8 regular + 2 block relay + temporary ones 11:39 < luke-jr> lightlike: so anchors? 11:40 < jonatack> lightlike: yes, I've attempted to communicate to the larger community that addnode conns are intended for trusted peers as an anti-eclipse protection 11:40 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has joined #bitcoin-core-dev 11:40 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 11:40 < _aj_> sipa: right, trying to understand what exactly the (unexpected/undesirable) consequences are though. is using an extra connection slot problematic? i could see it being bad if everyone did it, for sure... 11:41 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev 11:42 < sipa> _aj_: My point is more that it's not all that useful; if all you're doing is picking rumoured peers to connect to, why not let the automatic connection mechanism do its job? 11:42 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 11:43 < _aj_> sipa: you're filtering the rumoured peers by an uncommon service bit 11:43 < sipa> Doing the job the software should be doing for you :p 11:43 < sipa> But ok, fair, that's a benefit. 11:43 < _aj_> sipa: sure, but luke just said he'd want more review of a patch to fix that than he expects to get :) 11:43 < sipa> Fair enough. 11:43 < jonatack> lightlike: that twitter poll only had 160 respondants; it may be interesting to do one from an account with more reach like the bitcoin core org one 11:43 < lightlike> sipa: you can pick networks that way. automatic peering gives you no guarantees to have outbound connections to each network you like, it just picks random addrs from addrman 11:44 < luke-jr> jonatack (& anyone else): happy to retweet polls like this if you want to ping me with them ;) 11:44 < luke-jr> at least in my experience, my polls tend to get a lot of responses 11:45 -!- NorrinRadd [~me@188.215.95.225] has joined #bitcoin-core-dev 11:45 < jonatack> luke-jr: sgtm. laanwj was also happy to retweet. we can do some. 11:46 < jonatack> lightlike: yes. i have manual conns with tor, i2p and cjdns for instance. 11:47 < luke-jr> I have 3 addnodes, 1 probably dead (Eligius), and 2 I don't remember XD 11:48 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 11:53 -!- bomb-on [~bomb-on@user/bomb-on] has quit [Quit: aллилѹіа!] 11:59 < bitcoin-git> [bitcoin] omahs opened pull request #26402: Fix: typos (master...master) https://github.com/bitcoin/bitcoin/pull/26402 12:02 -!- mode/#bitcoin-core-dev [+o core-meetingbot] by ChanServ 12:02 < laanwj> #startmeeting 12:02 <@core-meetingbot> Meeting started Thu Oct 27 19:02:12 2022 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings. 12:02 <@core-meetingbot> Available commands: action commands idea info link nick 12:02 < brunoerg> hi 12:02 < instagibbs> oh hi 12:02 < luke-jr> hi 12:02 < vasild> hi 12:02 < ariard> hi 12:02 < josie[m]> hi 12:02 < hebasto> hi 12:02 < laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo 12:02 < laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild 12:02 < achow101> hi 12:02 < lightlike> hi 12:02 < laanwj> welcome to the weekly general bitcoin-core-dev meeting 12:02 < jarolrod> Hi 12:02 < ajonas> hi 12:03 < sipa> hi 12:03 < fjahr> hi 12:03 < Murch> hi 12:03 < pablomartin_> hello 12:03 < laanwj> no meeting topics have been proposed this week, but we still have some from last week from achow101: Adding (more) maintainers as GitHub org owners, Moratorium on refactors that are not part of larger projects that bring tangible features and fixes 12:03 < laanwj> any last minute ones? 12:03 < furszy> hi 12:04 < jonatack> hi 12:05 < laanwj> #topic High priority for review 12:05 <@core-meetingbot> topic: High priority for review 12:06 < b10c> hi 12:06 < laanwj> https://github.com/orgs/bitcoin/projects/1/views/1 6 blockers, 5 chasing concept ACK 12:06 < kouloumos> hi 12:06 < gleb071> hi 12:06 < laanwj> anything to add/remove? 12:06 < instagibbs> #26398 to replace #26265 please? 12:06 <@gribble> https://github.com/bitcoin/bitcoin/issues/26398 | Relax MIN_STANDARD_TX_NONWITNESS_SIZE to preclude 64 non-witness bytes only by instagibbs · Pull Request #26398 · bitcoin/bitcoin · GitHub 12:06 <@gribble> https://github.com/bitcoin/bitcoin/issues/26265 | POLICY: Relax MIN_STANDARD_TX_NONWITNESS_SIZE to 65 non-witness bytes by instagibbs · Pull Request #26265 · bitcoin/bitcoin · GitHub 12:07 < gleb071> i have #26359, it's small but still a blocker so may qualify i guess? 12:07 <@gribble> https://github.com/bitcoin/bitcoin/issues/26359 | p2p, refactor: #23443 (Erlay support signaling) follow-ups by naumenkogs · Pull Request #26359 · bitcoin/bitcoin · GitHub 12:08 < laanwj> instagibbs: as blocker or chasing concept ack? 12:08 < gleb071> the second batch PR is in draft and need little care, hopefully will be ready for review next week, so this is a good target for now :) 12:08 < instagibbs> laanwj, ah, i guess remove chasing concept ack on old, add high prio to new 12:08 < laanwj> gleb071: sure, size isn't important for this 12:08 < laanwj> instagibbs:ok! 12:09 < instagibbs> thanks! 12:09 < instagibbs> gleb071, great seeing forward motion :) 12:09 < laanwj> gleb071: added 12:10 < gleb071> thank you! you can drop the "meta-issue" from the last column too; not sure it's useful anymore 12:11 < gleb071> the issue is hopefully useful, but i think the distribution strategy can be different now 12:11 < laanwj> right, it's no longer waiting for concept ack 12:12 < gleb071> apparently i can edit the table? okay 12:13 < laanwj> the permissions on the github projects changed a while ago 12:13 < laanwj> i mean, the project boards... they're no longer part of a repository, but global to the organization, and have their own perissions 12:14 < laanwj> you must be in a team allowed to edit it 12:14 < gleb071> got it 12:15 < jarolrod> sound like a good segway into achow101 topic on org owners 12:15 < laanwj> you're only in "frequent contributors" which should have only read access to high prio for review... that's kinda weird 12:16 < laanwj> segway hehe 12:16 < laanwj> #topic Adding (more) maintainers as GitHub org owners (achow101) 12:16 <@core-meetingbot> topic: Adding (more) maintainers as GitHub org owners (achow101) 12:17 < jarolrod> for reference: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles 12:17 < gleb071> laanwj: i tested editing very moderately to not cause some org-wide notifications so it's possible you're right. i'm not interested enough to look further into that, but i can if you wish 12:17 < achow101> speaking of permissions, of the current owners of the bitcoin and bitcoin-core orgs, only 1 is a current maintainer, the rest former 12:18 < achow101> so I think it would make sense to have some of the current maintainers be added as owners as well 12:18 < laanwj> gleb071: i don't particularly care either, i'm sure everyone in the org is responsible enough not to do stupid things with the project board 12:18 < achow101> aiui, the main thing org owners do is administrative, and clean up spammers 12:18 < jarolrod> if a maintainer is an owner, and drops commit access, seems sane to drop org ownership as well 12:19 < luke-jr> but we should have more than 1 12:19 -!- bomb-on [~bomb-on@user/bomb-on] has joined #bitcoin-core-dev 12:19 < luke-jr> eg, in case someone gets hit by a bus 12:19 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 240 seconds] 12:19 < achow101> luke-jr: yes, that's mainly why I bring this up 12:19 < vasild> is that list public? 12:19 < luke-jr> achow101: but they can potentially do a lot more than spammer-triage 12:19 < jarolrod> org moderators can clean up spammers as well btw 12:19 < achow101> vasild: maybe? for contributors already part of the org, you can see who the owners are, not sure how public though 12:20 < vasild> ok 12:20 < laanwj> no, this isn't public, and maybe it's important to be somewhat discrete about who exactly has owner permissions, for bus factors etc 12:21 < vasild> then this is not suitable for public irc meeting? 12:21 < vasild> s/not/semi/ 12:21 < luke-jr> FWIW, lack of bitcoin org ownership prevented me from adding Kalle to the bips repo a while back, but I'm not sure I want that kind of access (in terms of becoming a possible target) 12:21 < laanwj> i'd agree adding one more maintainer would make sense though 12:21 < sipa> agree as well 12:21 < laanwj> not adding a maintainer but to the owners i mean 12:21 < luke-jr> laanwj: in terms of privacy, maybe it's best if there is no correlation with maintainers then? 12:21 -!- sipsorcery [~sipsorcer@37.228.225.67] has joined #bitcoin-core-dev 12:22 < jonatack> gleb071: i don't have any additional access priveleges and it looks like i could edit the project board too 12:22 < achow101> I think it would make sense for maintainersto be owners as owners can (force) push to protected branches 12:22 < jonatack> vasild: yes, it doesn't appear in, say, https://github.com/orgs/bitcoin-core/people that frequent contributors can see higher access privileges 12:22 < achow101> and so any owner would be a committer, even if their key is not in trusted-keys 12:22 < laanwj> luke-jr: i don't understand, you mean no one of the owners was available or wanted to add Kalle for you? 12:23 < luke-jr> laanwj: no, I mean I had to ask an owner to do it 12:23 < laanwj> oh, sure 12:23 < luke-jr> which is fine IMO 12:24 < laanwj> yeah... it doesn't seem like something that often happens, anyhow 12:24 < achow101> I think knowledge of who the owners are is semi public already, as we all know who to ping to cleanup spam 12:24 < luke-jr> [19:19:52] org moderators can clean up spammers as well btw 12:24 < luke-jr> so ownership of the org seems like a basically useless thing, but something we must maintain to avoid problems XD 12:25 < jonatack> achow101: yes, istm anyone following the repo closely can see who is cleaning up 12:25 < jarolrod> ^^ we don't have any moderators currently though 12:25 < glozow> achow101: to clarify you’re suggesting everyone in trusted-keys should also be org owners? 12:26 < luke-jr> jarolrod: I assume that's as easy to resolve as adding owners 12:26 < jarolrod> ^^ that would be too many owners 12:26 < jarolrod> i think he means of the owners, they should be a subset of current maintainers 12:26 < luke-jr> ^ 12:26 < achow101> luke-jr: I think org owners are also the only ones that can add new members? and also migrate repos in/out of the org (e.g. we might want to move libmultiprocess into bitcoin-core) 12:26 < luke-jr> achow101: ah 12:27 < glozow> oh i see 12:27 < jonatack> i'd suggest achow101, providing you are willing 12:27 < jarolrod> i'd suggest a specific maintainer who has a robot :D 12:27 < achow101> I am willing 12:27 < vasild> +1 12:28 < luke-jr> +1 for achow101 12:28 < ariard> ACK achow101 for org ownership 12:28 < gleb071> ACK 12:28 < josie[m]> ACK achow101 for org ownership 12:28 < b10c> ach ackow101 12:28 < fjahr> ACK 12:28 < josie[m]> very game of thrones vibe: "I am willing" 12:28 < luke-jr> ach? O.o 12:28 < pablomartin_> ack 12:29 < jonatack> b10c: nice inversion 12:29 < jarolrod> 👍 12:29 < laanwj> ok... seems we have agreement on that, at least inside the meeting 12:30 < glozow> ack 12:30 < laanwj> #topic Moratorium on refactors that are not part of larger projects that bring tangible features and fixes (achow101) 12:30 < Murch> +1 12:30 <@core-meetingbot> topic: Moratorium on refactors that are not part of larger projects that bring tangible features and fixes (achow101) 12:31 < sipa> Like with the question of adding maintainers, I think this is primarily a decision to be made by current maintainers/owners, as they have the best view on where help and of what kind is needed. Personally, ACK achow101. 12:32 < laanwj> yeah... but it's good to have broad agreement i guess 12:32 < achow101> We briefly discussed at coredev to reduce the number of refactors opened as they can have quite an effect on rebasing and review 12:33 < achow101> so perhaps we should stop opening refactoring prs that are not well motivated in the context of doing something larger that requires refactoring 12:34 < vasild> Such a moratorium seems like a blanket NACK on a vaguely defined set of changes. Who is deciding whether something is tangible? 12:34 < achow101> (this is both an effort to make it easier/faster to get things merged, and reduce the number of prs open) 12:34 < sipa> I agree it's pretty vague, and hard to decide anything about in general. 12:34 < sipa> But maybe you do have something more specific in mind (a few examples?) 12:34 < laanwj> it seems somewhat vague... maybe encourage people to nack specific refactors they disagree with? 12:35 < luke-jr> seems more like a vague suggestion 12:35 < instagibbs> or encourage people to state up front goals in refactoring PRs 12:35 < luke-jr> NACK is too strong - more like just silence on the PRs :P 12:35 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has quit [Ping timeout: 252 seconds] 12:35 < achow101> I suppose this is more of a "state your motivations" kind of suggestion, and perhaps think before refactoring 12:36 < laanwj> no i mean really nack, as in "yes it's a minor improvement but it's not worth it to change this many files" and things like that 12:36 < josie[m]> instagibbs: +1 , i think making a compelling argument for why you are doing something, and how it impacts further work is always a good idea 12:36 < _aj_> "-0 -- what is this building towards?" or something 12:36 < vasild> I think the current scheme works well: 1. if somebody bothered to write the code and 2. enough people think it is important enough and bother to review it and 3. some maintainer decides to merge it => then it is ok to have it in master 12:36 < sipa> I think it's generally helpful if there were more concept acks/nacks, even ones motivated as "unclear motivation". 12:37 < brunoerg> vasild: +1 12:37 < sipa> (certainly something I'm guilty off to, I prefer to stay silent on things I don't strongly dislike...) 12:37 < gleb071> The only two clear things we can do here is to say is to hear. I do share the opinion sometimes the refactorings are not justified given our review capacity. I will do my part in not producing such refactors. 12:37 < achow101> one example of such a refactor was a getInt thing in unvalue(?) from a few months ago that caused rebasing for no clear reason 12:37 < jonatack> it's hard to see this being more than a general encouragement, given the ad hoc nature of how we (prefer to work), but in general if the why doesn't make sense then the what probably doesn't matter, so that is always a good reason to well motivate PR descriptions 12:37 < gleb071> "is to say and to hear" i meant... 12:37 < luke-jr> achow101: I did NACK that, and got ignored 12:37 < lightlike> what is the intention behind "moratorium"? Disallow them periodically in a certain time span for each release cycle, or disallow them indefinitely "for now"? 12:38 < josie[m]> luke-jr: i kinda wished more people would NACK rather than be silent, so long as they take the time to explain why. it can be kinda frustrating with just silence because you dont know if people disagree or are just too busy 12:39 < luke-jr> josie[m]: I'd put refactoring moratorium as "just too busy" more than "disagree" IMO 12:39 < achow101> lightlike: indefinitely "for now" 12:39 < gleb071> We can think of inventing a new means of communication. Say, if you lack reviewes, you explicitly tag relevant devs. Then they feel better giving low-prio-nack. 12:41 < achow101> mainly this topic was to seed the ideas of either stop opening refactors, or be more agressive aboue nacking things 12:41 < vasild> The section "### Refactoring" in CONTRIBUTING.md is relevant to this and IMO is very well written 12:42 < ajonas> My concern is that a lot of the refactors that you may have in mind are authored by people not at this meeting. I think the best way to enforce would probably be to leave comments pushing for better motivation or NACKing (which requires work) and wait for the next kill, shill, merge session. Over time, that gets absorbed though it will also turn many newcomers away. 12:43 < jonatack> lightlike: there have been proposals in the past to concentrate refactorings at certain parts of the release cycles, but that didn't go further for the same reason as here (probably): an ad hoc approach seems more conducive to this open source project than top-down project management 12:43 < laanwj> newcomers really shouldn't open refactors :) 12:43 < _aj_> ajonas: (kill/shill/fulfill?) 12:43 < laanwj> that takes understanding of the code and purpose... we have that documented in CONTRIBUTING.md even 12:44 < josie[m]> aj: nice 12:45 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has joined #bitcoin-core-dev 12:45 < ajonas> laanwj: no argument from me. 12:46 < josie[m]> ajonas: i think this is a good point, and in any case, being more communicative on PRs can't hurt. im not sure about turning newcomers away tho. at least from my experience, the silence can be more discouraging then someone giving a (constructive) NACK 12:47 < laanwj> we used to have a lot of out of the blue refactores, which prompted that to be written, it's not a new issue really but also a complicated one 12:47 < _aj_> maybe point newcomers more at writing additional test coverage for existing code? 12:47 < luke-jr> I noticed earlier a dumb refactor simply closed with no comment. I imagine that's pretty discouraging <.< 12:48 < laanwj> josie[m]: i definietly agree to that (from my own experience of outside contributor to projects) 12:48 < luke-jr> https://github.com/bitcoin/bitcoin/pull/26374 12:48 < laanwj> "no i don't want this" is better than just silence for months or it lingering for years even 12:48 < jonatack> maybe a canned response can be given to newcomer refactors. that said, from what i've seen when a newcomer proposes an intelligent|useful cleanup or refactoring, it not only tends to be well- 12:48 < jonatack> received but also perhaps gets attention and merge more quickly 12:49 < jonatack> which could encourage more refactoring perhaps 12:49 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has quit [Ping timeout: 246 seconds] 12:49 < fjahr> adding tests is good but also fixing actual bugs, there are enough open issues. But for a newcomers that is probably a lot of work and many seem to look for instant gratification. 12:49 < laanwj> as a contributor you're generally aware not everything will be merged and there can be disagreements 12:50 < jonatack> as refactoring outwardly may seem easier to review as well and divert review attention (as mentioned a bit earlier above in the meeting) 12:51 < josie[m]> laanwj: +1 12:51 < laanwj> fjahr: hah yes... a long time ago there used to be this awful system that paid out per commit... this encouraged a lot of people to try to get *something* into bitcoin core, the most trivial and cosmetic changes 12:52 < sipa> that was terrible, i remember 12:52 < josie[m]> jonatack: i think the fact that refactors appear to be easy can also make them very dangerous, as in they might not get as thorough a review there is a non-zero chance they introduce subtle bugs 12:52 < achow101> jonatack: even "useful cleanups" are detrimental as they can cause conflicts with other things and delay other PRs from being merged 12:52 < luke-jr> I think we did lose a developer over that being shutdown tho 12:52 < _aj_> luke-jr: seems like a better pr than solidity got https://github.com/ethereum/solidity/pull/13646 at least 12:52 < gleb071> hacktoberfest 12:52 < jonatack> josie[m]: achow101: agree 12:52 < kanzure> does gh-meta capture comment edits? 12:52 < luke-jr> _aj_: hahahah lol 12:53 < ajonas> fjahr: strongly agree here but really hard to find the right entry point. Good first issues has produced varied results. 12:53 < sipa> kanzure: I think so. 12:53 < laanwj> kanzure: it should 12:53 < sipa> luke-jr: I do believe we lost one somewhat-useful contributor over this. 12:53 < sipa> Who got really demotived when told to reduce the number of commits in PRs. 12:53 < sipa> *demotivated 12:53 < jonatack> josie[m]: indeed, refactors have been a real source of non-trivial bugs 12:54 < vasild> "that was terrible, i remember" -- it can be worse, it can pay per number of added lines. 12:54 < laanwj> vasild: lol... someone might add a flight simulator! 12:54 < sipa> jonatack: Do you have an example? (not disagreeing, just kind of wondering what you're thinking of) 12:54 < vasild> yes :-D 12:54 < sipa> I think we need built-in tetris in the GUI. 12:54 < sipa> As RNG source, or something. 12:55 < laanwj> hehe 12:55 < laanwj> mempool tetris 12:55 < vasild> hmm, actually it may make sense to pay per _removed_ lines (off topic, sorry) 12:55 < josie[m]> id start contributing to the bitcoin GUI if we had built in tetris :D 12:55 < kanzure> coin selection and tetris are both examples of the same class of problem 12:55 < ajonas> _aj_: (kill/shill/thrill?) 12:55 < jarolrod> sipa: that can be accommodated 12:55 < luke-jr> vasild: [19:48:08] https://github.com/bitcoin/bitcoin/pull/26374 12:55 < _aj_> ajonas: thrill is when it gets mentioned in an optech newsletter 12:56 < jonatack> sipa: refactorings touching the init order bring to mind a couple 12:56 < laanwj> yes init order (especially in the gui, as there are lots of hard to test edge cases) is really dangerous to change, agree jonatack 12:56 < kanzure> is the concern about the set of open PRs being too plentiful, or that an old refactor becomes virtually useless over time due to staleness? 12:56 < _aj_> oh, i have a question about init (shutdown) order. can wait to post meeting in a few mins 12:57 < luke-jr> inb4 _aj_ refactors init/shutdown order for no reason (jk) 12:57 < jarolrod> Play Tetris while core syncs 12:57 < laanwj> kanzure: i was thinking of transaction selection for blocks, but coin selection works too 12:58 < _aj_> nah, it's just what seems like a bug 12:59 < jonatack> laanwj: i think i recall one causing UB and a re-release (nov/dec 2020?) and one causing an addrman corruption issue (july/aug 2021) 13:00 < laanwj> jonatack: yes, you'er right 13:00 < laanwj> ok, time to close the meeting 13:00 < laanwj> #endmeeting 13:00 <@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 13:00 <@core-meetingbot> Meeting ended Thu Oct 27 20:00:33 2022 UTC. 13:00 <@core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2022/bitcoin-core-dev.2022-10-27-19.02.moin.txt 13:00 < _aj_> okay, so i feel like i've seen a hang on shutdown a bunch of times -- recently i caught something like it in gdb 13:01 < kanzure> fyi gnusha was down for a few days, log contributions welcome 13:01 < kanzure> (i need to install a watcher/notifier) 13:01 < luke-jr> _aj_: yes, I think I diagnosed one previously - not sure it got fixed 13:02 < luke-jr> https://github.com/bitcoin/bitcoin/issues/23234 13:02 < _aj_> that one seemed to be traced the parallel script checking threads hanging on shutdown, i think because they were waiting for SyncWithValidationInterfaceQueue() to finish, but it was hanging on the schedule to finish a promise, and the scheduler thread was already stopped 13:03 < jonatack> _aj_: have been seeing hangs on shutdown too 13:04 < _aj_> luke-jr: so i fixed that locally by just having SyncWithValidationInterfaceQueue exit early if shutdown's requested; but had to make the promise be a shared_ptr, so that when the scheduler got cleared, it hadn't already been freed 13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 272 seconds] 13:04 < luke-jr> _aj_: you found a different one then? 13:05 < _aj_> luke-jr: LimitValidationInterfacequeue calls SyncWithValidationInterfaceQueue, so seems similar? 13:06 < vasild> _aj_: https://github.com/bitcoin/bitcoin/pull/26188 is relevant 13:06 < vasild> to SyncWithValidationInterfaceQueue() 13:06 < vasild> I found the code surrounding is gives me a headache 13:07 < vasild> s/is/it/ 13:08 * vasild zZzZ 13:08 < jeremyrubin> jonatack: i think i proposed having refactor windows a while back, but it was sort of a stopgap of retaining contributors whose utility function is driven by refactors 13:09 < jeremyrubin> Jan 20th 2022 for the logs 13:09 < jeremyrubin> https://gnusha.org/bitcoin-core-dev/2022-01-20.log 13:09 < jonatack> jeremyrubin: yes, i had that proposal in mind 13:10 < luke-jr> I guess that's a risk of refactor moratorium: we might lose people who only do refactoring :x 13:10 < luke-jr> ideally they'd review other stuff in the meantime, but they might not want to 13:11 < jeremyrubin> so one of the worst things for refactors is fixing circular deps because it definitely makes rebasing crappy (unless someone has some expert mode git-fu) 13:11 < jeremyrubin> but it is something that is a part of "a project" to fix bad design/improve compile times or something 13:12 < _aj_> improving compile times is a larger project, and something you can benchmark to demonstrate the benefit... 13:12 < luke-jr> I'm not sure a project which has refactoring as its sole purpose, qualifies :P 13:14 < bitcoin-git> [bitcoin] instagibbs opened pull request #26403: Ephemeral anchors (master...ephemeral-anchors) https://github.com/bitcoin/bitcoin/pull/26403 13:16 -!- NorrinRadd [~me@188.215.95.225] has quit [Quit: NorrinRadd] 13:18 < jeremyrubin> _aj_: sort of -- for circular dependencies you could have module A depending on module B which depends on A and module C which depends on A which depends on B. Cleaning up A's dependency on B would not make any improvement until the work on removing B and A from C (if i've made the example well), but would be progress towards that goal if C is 13:18 < jeremyrubin> trickier to refactor than A/B. 13:18 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has joined #bitcoin-core-dev 13:19 < jeremyrubin> i also don't know if there is any compile time overhead for circular dependencies, not familiar enough with exactly how it works to know if there is a penalty (seems if LTO is enabled, yes, if not, headers solve for that) 13:20 < sipa> You do need to distinguish the "module/semantic" circular dependencies and "code inclusion" circular dependencies. 13:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:61af:29e6:299:1537] has quit [] 13:28 -!- sudoforge [~sudoforge@wireguard/tunneler/sudoforge] has quit [Ping timeout: 240 seconds] 13:33 < BlueMatt[m]> is there any reason to think bitcoin core rpc would not return stale forked-off blocks if requested by hash? 13:34 < _aj_> BlueMatt[m]: pruning? 13:36 < BlueMatt[m]> yea, i asked about pruning, i dont think that was the issue here. I was just double-checking that no one introduced any kind of "old stale" check before returning block data in rpc 13:37 < BlueMatt[m]> bug may well be elsewhere, just checking off boxes 13:37 < sipa> Is this in `getblock` ? 13:37 < sipa> I don't see any logic in the getblock RPC that would reject requests for non-mainchain blocks. 13:37 < sipa> It only affects the "confirmation" field. 13:37 < _aj_> BlueMatt[m]: getting old blocks that are listed in chaintips via getblock is working fine for me fwiw 13:38 < laanwj> i don't think there's such a check for RPC, it would be really strange, unless it's somehow inherited from P2P where there's checks like that against fingerprinting 13:38 < instagibbs> wasnt there a PR to make it stop sending these after a month 13:38 < instagibbs> anti-fingerprinting 13:38 < instagibbs> or is this just p2p 13:38 < instagibbs> sorry, ignore 13:38 < sipa> Just P2P, I believe. 13:38 < laanwj> it would be kind of bad if that was for RPC 13:38 < instagibbs> agreed! 13:40 < BlueMatt[m]> Thanks y’all. Yea, would be bad. 13:40 < BlueMatt[m]> Oh, there’s nothing like that in REST either, right v 13:40 < BlueMatt[m]> ? 13:40 < laanwj> rest and rpc tend to follow exactly the same path 13:41 < sipa> Just checked rest, can't see logic there either. 13:41 < sipa> Except for JSON block output, where again it's used for confirmations. 13:43 < BlueMatt[m]> hmm, okay, thanks....strange bug, then. 13:53 < jonatack> instagibbs: i suppose "ephemeral anchors" is vocabulary originating from anchor outputs in lightning, but the term is similar to our existing p2p anchors (last known outbound block-relay-only peers that we try to re-connect to on startup) 13:55 < jonatack> naming collisions ftw i guess 13:58 < instagibbs> yeah we can bikeshed for the next year or two, all for it 13:58 < instagibbs> first, make sure it's not broken 13:59 < instagibbs> (it's broken) 14:08 < _aj_> "ephemeral cpfp hook" ? surely it won't take a year or two... 14:09 < jonatack> _aj_ is good with words; nominated for terms naming 14:09 < instagibbs> three words now, great. 14:10 < jonatack> ecpfphook 14:10 < instagibbs> phook it is 14:10 < jonatack> yess 14:10 < _aj_> get phooked? 14:10 < jonatack> catchy > literal 14:11 < jonatack> like band names 14:21 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has quit [Ping timeout: 240 seconds] 14:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 14:27 -!- dviola [~diego@user/dviola] has quit [Ping timeout: 240 seconds] 14:28 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 14:30 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 14:37 < bitcoin-git> [bitcoin] sipa closed pull request #26076: Switch hardened derivation marker to h in descriptors (master...2022/09/descriptors_h) https://github.com/bitcoin/bitcoin/pull/26076 14:37 < bitcoin-git> [bitcoin] sipa reopened pull request #26076: Switch hardened derivation marker to h in descriptors (master...2022/09/descriptors_h) https://github.com/bitcoin/bitcoin/pull/26076 14:38 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 258 seconds] 14:41 -!- dviola [~diego@179.235.13.211] has joined #bitcoin-core-dev 14:42 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 14:49 -!- robertnielsen [~robertnie@c-67-164-56-127.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 14:49 < bitcoin-git> [bitcoin] achow101 pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/551c8e9526d2...f37bd15d472f 14:49 < bitcoin-git> bitcoin/master 94c0766 furszy: wallet: skip available coins fetch if "other inputs" are disallowed 14:49 < bitcoin-git> bitcoin/master 37e7887 furszy: wallet: skip manually selected coins from 'AvailableCoins' result 14:49 < bitcoin-git> bitcoin/master 295852f furszy: wallet: encapsulate pre-selected-inputs lookup into its own function 14:49 < bitcoin-git> [bitcoin] achow101 merged pull request #25685: wallet: Faster transaction creation by removing pre-set-inputs fetching responsibility from Coin Selection (master...2022_wallet_faster_coin_selection) https://github.com/bitcoin/bitcoin/pull/25685 14:51 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has joined #bitcoin-core-dev 14:56 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has quit [Ping timeout: 246 seconds] 15:08 < bitcoin-git> [bitcoin] mzumsande opened pull request #26404: test: fix intermittent failure in rpc_getblockfrompeer.py (master...202210_testfix_blockfrompeer) https://github.com/bitcoin/bitcoin/pull/26404 15:10 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has joined #bitcoin-core-dev 15:18 -!- Guest9 [~Guest9@92.58.169.54] has joined #bitcoin-core-dev 15:19 -!- Guest9 [~Guest9@92.58.169.54] has quit [Client Quit] 15:35 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-dev 15:46 -!- sipsorcery [~sipsorcer@37.228.225.67] has quit [Ping timeout: 250 seconds] 15:47 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev 16:05 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 258 seconds] 16:08 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 258 seconds] 16:09 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.7.1] 16:10 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 16:12 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 16:14 -!- lightlike [sid521075@user/lightlike] has quit [Ping timeout: 264 seconds] 16:17 -!- lightlike [sid521075@user/lightlike] has joined #bitcoin-core-dev 16:18 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has quit [Ping timeout: 240 seconds] 16:20 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has joined #bitcoin-core-dev 16:23 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 244 seconds] 16:41 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 258 seconds] 16:48 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 17:36 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 17:43 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 17:50 -!- nanotube [~nanotube@user/nanotube] has joined #bitcoin-core-dev 17:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 17:52 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 258 seconds] 17:54 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 18:08 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 18:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 18:46 -!- yanmaani2 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev 18:50 -!- amovfx_ [~amovfx@node-1w7jr9yi65te62vzbflhgse0k.ipv6.telus.net] has quit [Remote host closed the connection] 18:51 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has joined #bitcoin-core-dev 18:56 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev 19:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 19:00 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has quit [Ping timeout: 255 seconds] 19:11 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev 19:14 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds] 19:16 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 258 seconds] 19:18 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 19:21 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has joined #bitcoin-core-dev 20:13 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 258 seconds] 20:18 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev 20:25 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has quit [Ping timeout: 240 seconds] 20:36 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 20:36 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 20:39 -!- amovfx_ [~amovfx@node-1w7jr9yi65te76avgv6tof5ba.ipv6.telus.net] has joined #bitcoin-core-dev 20:43 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 20:43 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 20:45 -!- amovfx_ [~amovfx@node-1w7jr9yi65te76avgv6tof5ba.ipv6.telus.net] has quit [Ping timeout: 252 seconds] 20:46 -!- amovfx [~amovfx@node-1w7jr9yi65te69rn8k46zdsox.ipv6.telus.net] has quit [Ping timeout: 244 seconds] 20:50 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 20:51 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 20:53 -!- amovfx [~amovfx@node-1w7jr9yi65te4fuxljle3u02k.ipv6.telus.net] has joined #bitcoin-core-dev 20:54 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has joined #bitcoin-core-dev 20:58 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 20:58 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection] 21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev 21:03 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev 21:05 -!- zeropoint [~alex@c-67-169-157-130.hsd1.ca.comcast.net] has quit [Quit: leaving] 21:05 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:05 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:12 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:12 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:19 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:20 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:27 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:27 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:28 -!- pablomartin_ [~pablomart@37.120.148.174] has quit [Ping timeout: 244 seconds] 21:34 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:34 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:42 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:42 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:45 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 258 seconds] 21:49 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:49 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:55 -!- amovfx [~amovfx@node-1w7jr9yi65te4fuxljle3u02k.ipv6.telus.net] has quit [Ping timeout: 246 seconds] 21:55 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 21:56 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 21:56 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 21:57 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has quit [Ping timeout: 246 seconds] 22:03 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:03 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:10 -!- amovfx [~amovfx@node-1w7jr9yi65te4fuxljle3u02k.ipv6.telus.net] has joined #bitcoin-core-dev 22:11 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:11 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:18 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:18 -!- jamesob [~jamesob@151.200.19.227] has quit [Read error: Connection reset by peer] 22:18 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:19 -!- jamesob [~jamesob@151.200.19.227] has joined #bitcoin-core-dev 22:22 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has joined #bitcoin-core-dev 22:25 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:25 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:32 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:33 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:39 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:39 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:45 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:46 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:52 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:52 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 22:58 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 22:59 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:05 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:05 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:09 -!- amovfx [~amovfx@node-1w7jr9yi65te4fuxljle3u02k.ipv6.telus.net] has quit [Ping timeout: 255 seconds] 23:11 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:11 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:18 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:18 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:25 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:25 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:25 -!- amovfx_ [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has quit [Ping timeout: 255 seconds] 23:32 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:32 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:38 -!- amovfx [~amovfx@node-1w7jr9yi65te4fuxljle3u02k.ipv6.telus.net] has joined #bitcoin-core-dev 23:38 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:38 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:43 -!- amovfx [~amovfx@node-1w7jr9yi65te4fuxljle3u02k.ipv6.telus.net] has quit [Ping timeout: 276 seconds] 23:45 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:45 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:51 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:51 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:54 -!- amovfx [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has joined #bitcoin-core-dev 23:58 -!- greypw2546002 [~greypw254@grey.pw] has quit [Remote host closed the connection] 23:58 -!- greypw2546002 [~greypw254@grey.pw] has joined #bitcoin-core-dev 23:58 -!- amovfx [~amovfx@node-1w7jr9yi65te42f98qsv2cp22.ipv6.telus.net] has quit [Ping timeout: 246 seconds] --- Log closed Fri Oct 28 00:00:00 2022