--- Log opened Tue Dec 15 00:00:48 2020
00:12 < yanmaani> When running Core, I got the following error, because my blocks/ folder was a broken symlink (target unmounted):
00:13 < yanmaani> boost::filesystem::create_directory: File exists: "/x/Data/blocks"
00:13 < yanmaani> I'm curious - where is the call to create_directory? Because it's only used in tests, as far as I can see
00:15 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:23 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection]
00:27 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev
00:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:29 < bitcoin-git> [gui] jonasschnelli merged pull request #115: Replace "Hide tray icon" option with positive "Show tray icon" one  (master...201024-tray) https://github.com/bitcoin-core/gui/pull/115
00:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:29 < bitcoin-git> [bitcoin] jonasschnelli pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/94a9cd25fd17...33d633726922
00:29 < bitcoin-git> bitcoin/master 17174f8 Hennadii Stepanov: gui: Replace "Hide tray icon" option with positive "Show tray icon" one
00:29 < bitcoin-git> bitcoin/master 03edb52 Hennadii Stepanov: qt: Remove redundant BitcoinGUI::setTrayIconVisible
00:29 < bitcoin-git> bitcoin/master 33d6337 Jonas Schnelli: Merge bitcoin-core/gui#115: Replace "Hide tray icon" option with positive ...
00:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:30 < jonasschnelli> yanmaani: GetBlocksDir() in system.cpp
00:31 < yanmaani> ah, thanks
00:33 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
00:34 < jnewbery> andytoshi: if you're mining to the wallet's address, you could call generate(), get the block hash, fetch the coinbase txid, and then wait_until() the wallet's listunspent includes that transaction output
00:51 -!- pwgn [~pwgn@139.28.218.148] has quit [Remote host closed the connection]
01:08 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
01:12 -!- creffett|irssi [~creffett|@185.163.110.125] has joined #bitcoin-core-dev
01:14 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.29-209.dynamic.3bb.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:17 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
01:20 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Remote host closed the connection]
01:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:40 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
01:58 -!- promag_ [~promag@188.250.84.129] has quit [Ping timeout: 260 seconds]
01:59 -!- promag_ [~promag@188.250.84.129] has joined #bitcoin-core-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-174.cust.tzulo.com] has quit [Ping timeout: 260 seconds]
02:47 -!- hhghhkqweaeasd [~flack@p200300d46f24de0023b487635c149e9b.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:47 -!- kljasdfvv [~flack@p200300d46f24de00a3ce7892b0332293.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
02:57 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.29-209.dynamic.3bb.co.th] has joined #bitcoin-core-dev
03:03 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
03:04 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
03:18 -!- Britney33Rosenba [~Britney33@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:22 -!- Britney33Rosenba [~Britney33@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]
03:28 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
03:30 < wumpus> luke-jr: qthreadpoolthread is used with qthreadpool, which is used by qconcurrent (high level concurrency framework), neither of which we AFAIK currently use... even then, 64 seems excessive, but i guess they didn't really think about the scenario with so many cores. They should all be constantly sleeping so I guess it's not much overhead besides some memory
03:31 < wumpus> using QRunnable for some things sounds interesting
03:35 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
03:37 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.29-209.dynamic.3bb.co.th] has quit [Ping timeout: 256 seconds]
04:25 -!- creffett|irssi [~creffett|@185.163.110.125] has quit [Remote host closed the connection]
04:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:49 < bitcoin-git> [bitcoin] fanquake pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/33d633726922...f1f2418433c9
04:49 < bitcoin-git> bitcoin/master 2f3f1ae fanquake: net: remove SetMaxOutboundTarget
04:49 < bitcoin-git> bitcoin/master b117eb1 fanquake: net: remove SetMaxOutboundTimeframe
04:49 < bitcoin-git> bitcoin/master 173d0d3 fanquake: net: remove nMaxOutboundTimeframe from connection options
04:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:49 < bitcoin-git> [bitcoin] fanquake merged pull request #20253: net: use std::chrono throughout maxOutbound logic (master...net_unused_outbound) https://github.com/bitcoin/bitcoin/pull/20253
04:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:56 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
05:13 -!- einyx [einyx@fsf/member/einyx] has quit [Ping timeout: 256 seconds]
05:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:16 < bitcoin-git> [bitcoin] Sjors opened pull request #20660: Move signet onion seed from v2 to v3 (master...2020/12/signet-v3-onion) https://github.com/bitcoin/bitcoin/pull/20660
05:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:26 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
05:29 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
05:29 -!- spake [~spake@178.162.209.171] has joined #bitcoin-core-dev
05:34 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has joined #bitcoin-core-dev
05:36 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
05:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
05:36 -!- vasild_ is now known as vasild
05:40 -!- lontivero [~lontivero@186.183.3.236] has joined #bitcoin-core-dev
05:50 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
05:53 -!- einyx [~einyx@fsf/member/einyx] has joined #bitcoin-core-dev
05:53 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
05:54 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
05:55 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
05:56 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
06:03 -!- Lightlike [b9ff439e@185.255.67.158] has joined #bitcoin-core-dev
06:05 -!- Lightlike [b9ff439e@185.255.67.158] has left #bitcoin-core-dev []
06:08 -!- Kiminuo [~mix@141.98.103.172] has joined #bitcoin-core-dev
06:11 -!- einyx [~einyx@fsf/member/einyx] has quit [Ping timeout: 272 seconds]
06:12 -!- einyx_ [~einyx@fsf/member/einyx] has joined #bitcoin-core-dev
06:13 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
06:19 -!- vincenzopalazzo [~vincent@2001:b07:6474:9d49:5809:f8dd:2776:36cd] has joined #bitcoin-core-dev
06:21 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has quit [Ping timeout: 260 seconds]
06:30 -!- Kiminuo [~mix@141.98.103.172] has quit [Read error: Connection reset by peer]
06:34 < jnewbery> Hi folks. We have a p2p meeting in half an hour. Only one proposed topic so far: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#15-dec-2020. Feel free to add topics between now and 15:00 UTC.
06:34 < gribble> https://github.com/bitcoin/bitcoin/issues/15 | Option to specify external IP address · Issue #15 · bitcoin/bitcoin · GitHub
06:35 < jnewbery> We won't have our normal meeting in two weeks' time (29 Dec), so this is the last p2p meeting of the year. The next will be on 12 Jan 2021.
06:35 < harding> I heard there was a problem with osx signing.  Does that mean https://bitcoincore.org/bin/bitcoin-core-0.21.0/test.rc3/bitcoin-0.21.0rc3-osx.dmg is not going to work or will print some scary warning to users who try to run it?
06:36 -!- Kiminuo [~mix@141.98.103.108] has joined #bitcoin-core-dev
06:46 < jonasschnelli> harding: it will not run
06:46 < jonasschnelli> harding: but you can use the unsigned version and right-click start it
06:46 < harding> jonasschnelli: ok, good to know.  Thanks!
06:56 -!- miketwenty1 [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
06:56 -!- miketwenty1 [~miketwent@136.55.84.49] has quit [Remote host closed the connection]
06:57 -!- miketwenty1 [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
07:00 < MarcoFalke> meeting?
07:01 < jnewbery> #startmeeting
07:01 < core-meetingbot> Meeting started Tue Dec 15 15:01:02 2020 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
07:01 < core-meetingbot> Available commands: action commands idea info link nick
07:01 < jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb 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 petertodd 
07:01 < gleb> Hi
07:01 < jnewbery> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
07:01 -!- Lightlike [b9ff439e@185.255.67.158] has joined #bitcoin-core-dev
07:01 < jonatack> hi
07:01 < ariard> hi
07:01 < aj> hey
07:01 < ajonas> Hi
07:01 < jnewbery> hi all. Welcome to the last p2p meeting of 2020!
07:01 < fanquake> hi
07:02 < jnewbery> We have one proposed topic: Review of the P2P Review Process (ariard). Before we get into that, does anyone have any proposed topics that they want to add?
07:03 < jnewbery> ok, onto our one topic
07:03 < jnewbery> #topic Review of the P2P Review Process (ariard)
07:03 < core-meetingbot> topic: Review of the P2P Review Process (ariard)
07:03 < ariard> hi
07:04 < ariard> so as it's the last p2p meeting of 2020, it's a great opportunity to review our p2p review process
07:05 < ariard> so I just have an opening question and let's discuss from it
07:05 < ariard> which PR reviews stand-out as productive and which were productive ?
07:05 < ariard> is there anything we can learn from these examples
07:05 < ariard> I did attach some past PRs on the wiki page : https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
07:06 < ariard> let's start by a roundtable, can anyone tell one PR review liked on the past year :) ?
07:06 < gleb> I think the topic is worthy but it’s much broader then what we can discuss here in tea time, although gathering initial thoughts might work  
07:07 < gleb> in real time*
07:07 < ariard> gleb: that's fine start by sharing your initial thoughts
07:07 < MarcoFalke> So I think the review process hasn't changed fundamentally in the past years. We made some minor changes to ACKs (allowing them to be more verbose, Approach, Concept, ...), also there is a REVIEWERS file where people can sign up for notifications if their watched file changes...
07:07 -!- Kiminuo [~mix@141.98.103.108] has quit [Ping timeout: 256 seconds]
07:08 < MarcoFalke> Though, based on the blog post by ajonas many raised a concern that review isn't focussed enough.
07:08 < gleb> I haven’t really noticed REVIEWERS file in action yet, although I liked the concept
07:08 < MarcoFalke> I see that too, escpecially on larger pulls.
07:08 < kanzure> there was a recent twitter survey asking whether reviews feel different lately. an actual non-twitter survey might be helpful.
07:08 < ariard> MarcoFalke: which blog post? didn't read it
07:09 < gleb> kanzure: ack but asking the right question matters 
07:09 < jonatack> ariard: in general, i can think of many outstanding reviews (and there are some outstanding reviewers). Coverage of great reviews was actually proposed one year ago for Bitcoin Optech: https://github.com/bitcoinops/bitcoinops.github.io/issues/301 
07:09 < MarcoFalke> ariard: kanzure: ajonas did a writeup on a 2019 survey
07:09 < MarcoFalke> was shared in the last general meeting
07:09 < ariard> ah this one, okay
07:09 < ajonas> https://adamjonas.com/bitcoin/coredev/retro/coredev-2019-retro/
07:10 < MarcoFalke> So I think it would be good if there was a signal where a contributor could simply express interest in doing a review (at a later time)
07:10 < jonatack> ariard: I have a short exposition on this topic that I wrote in reply to your question yesterday, can present it here after the meeting or maybe a as twitter thread
07:11 < ariard> jonatack: yes I feel sometimes it's hard to have a clear overview of what's the blocker for the PR (waiting author, dependency, moar-concept-ack, metrics, ...)
07:11 < MarcoFalke> Then, it would be easier for maintainers to gather how much review interest there is and based on that ping people at around the same time to start digging into the review
07:12 < ariard> MarcoFalke: agree, 19858 is a good example, it's a PR with a lot of context and you want to avoid wasting review time if your the only one doing a review for the coming month
07:12 < MarcoFalke> It could be as simple as saying "Concept ACK (willing to upgrade to review ACK)"
07:12 < ariard> a recent good example
07:12 < MarcoFalke> #19858 
07:12 < gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
07:12 < jnewbery> MarcoFalke: for myself, if I've concept ACKed a PR, then it almost always means that I intend to review the code later (and would be receptive to the author/maintainer pinging me if I hadn't)
07:13 < aj> personally, i'm bothered by https://github.com/bitcoin/bitcoin/pull/20599#issuecomment-741631081 ; my opinion is that we should be thoroughly reviewing all p2p changes because there's potential for interactions, so going easy on "boring" PRs seems very unsafe. beyond that, there's a lot of not very beneficial refactoring PRs, that are also causing extra dev and review rework on PRs that change the 
07:13 < aj> code's behaviour
07:13 < MarcoFalke> jnewbery: I think we can't assume that generally. Often I say Concept ACK, but I mean "Concept ACK, but I am not confident in reviewing this or I don't have the motivation"
07:13 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
07:14 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
07:14 < MarcoFalke> ariard: Good example. The pull had 4 ACKs at some point, but was merged with less. I think it was a bit unclear to maintainers if more people are interested in testing/reviewing or if the review motivation has been used up already on that pull
07:15 < ariard> aj: agree and you have to spend a lot of time just to have confidence you have you don't have interactions, even slight ones
07:16 < ajonas> I think encouraging opinions often and early is the main goal of a concept/approach ACK. People may have varying interest in following up as the PR moves into a lower-level kind of review.
07:16 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Quit: Pavlenex]
07:16 < jnewbery> MarcoFalke: I think that's fair. My default (concept ACK implies a later review ACK and explicitly say "I won't review this later" if you don't intend to review later) is perhaps the opposite from other people.
07:16 < ariard> I do feel sometimes stack small refactor in bigger PR, even with bigger diff might be actually to review, because less cognitive spreading to reload the code model each time
07:17 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has joined #bitcoin-core-dev
07:17 < ariard> MarcoFalke: yes I think that's a good initiative for maintainers to ping/engage past reviewers if they're still interested to review  again
07:18 < MarcoFalke> aj: Also a good point. I think it would be easier for maintainers to know how much resistance there is if NACKs or ~mehs were thrown out more agressively
07:18 < aj> ariard: i think limiting refactors to ones that are immediately useful as part of either implementing a feature, fixing a bug or improving automated tests would be a huge improvement. (or perhaps as followups to a PR that's hit its preserve-acks-no-more-nits limit)
07:18 < MarcoFalke> I have the feeling that many shy away from a NACK or -0, but that shouldn't be
07:18 < jonatack> ariard: i agree (and do that) but bigger PRs scare off reviewers and it doesn't always work out. knowing how much to put in a PR and how much to leave out is the hardest part for me TBH
07:19 < jnewbery> aj: 20599 was thoroughly reviewed. It had 5 ACKs
07:19 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
07:20 < ariard> aj: yes what we might have to weight more carefully is the "immediately" I feel for some features you will have to stack multiple refactors before to have the ground ready for new stuff, e.g mempool
07:20 < aj> ariard: immediately == different commits in the same PR
07:21 < aj> ariard: or, like taproot, commits pulled out of a large PR that's already open and available for review
07:21 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Client Quit]
07:21 -!- miketwen_ [~miketwent@ec2-3-216-176-187.compute-1.amazonaws.com] has joined #bitcoin-core-dev
07:21 < ariard> aj: okay but not preparatory-PR-for-some-future-feature, like sdaftuar did for motivating workspace in mempool a back while?
07:22 < aj> ariard: the package relay stuff? it had a concurrent PR implementing packages via orphans?
07:22 < ariard> aj: this one https://github.com/bitcoin/bitcoin/pull/16400
07:23 < ariard> which was a substantial diff
07:23 < aj> ariard: yeah, it had #16401
07:23 < gribble> https://github.com/bitcoin/bitcoin/issues/16401 | Add package acceptance logic to mempool by sdaftuar · Pull Request #16401 · bitcoin/bitcoin · GitHub
07:23 -!- mj_node [~mj_node@122.0.25.130] has joined #bitcoin-core-dev
07:24 < ariard> jonatack: yeah I've a preference for a bit more substantial PR but it's so much tied to everyone review workflow
07:24 < ariard> and past experience with a part of the codebase
07:24 < jonatack> MarcoFalke: one thing it might be helpful to have signals from maintainers about, is if follow-ups are desired for the review comments that weren't taken or for missing coverage, e.g. 19858 would be an example
07:24 -!- miketwenty1 [~miketwent@136.55.84.49] has quit [Ping timeout: 246 seconds]
07:25 < jonatack> ariard: yes
07:26 < ariard> aj: my point is sometimes it can be hard to justify one-individual-refactor but they make sense when you zoom out or point to following PR
07:26 < ariard> like if we move towards isolating block-relay from tx-relay, it won't happen with one big PR?
07:26 < MarcoFalke> jonatack: As a maintainer I try to keep those decicions up to the reviewers/other contributors. I don't want to "rule" the project too much.
07:26 < jonatack> MarcoFalke: that's fair
07:27 < ariard> jonatack: I do feel we could track follow-ups better, most of the time it's not they're relevant, it's just to much changes for a PR or the PR is already super mature
07:27 < ariard> GH doesn't have a follow-ups pinning board?
07:27 < jonatack> ariard: I also like PRs that do things well, even if that makes them more substantial...not sure if I would have said the same a year ago, though
07:28 < ariard> jonatack: agree to have them strong test coverage, but when it's code style or slight features changes the list of follow-ups might be infinite?
07:28 < gleb> ariard: explicitly motivating refactors with some future work would help.
07:28 < aj> ariard: if you can point to a following PR, include the refactor in that PR
07:30 < ariard> gleb: yes it sounds tied to context-tracking, maybe we could improve it with the wiki? it's widely used to advertise state of the ongoing work around i2p?
07:31 < jonatack> ariard: yes, in practice i mostly leave it to the PR author to follow-up or not, there are always other priorities to do and review
07:31 < aj> ariard: isn't creating an issue the obvious thing to do if a PR needs followups and you can't just create the followup PR straight away?
07:31 < jonatack> that's probably what most do
07:31 < gleb> ariard: I think even just mentioning it in the first PR comment would help. Wiki stuff may be too much.
07:32 < ariard> jonatack: right I think it's the job of the reviewer to clearly say when comments are blockers or nice-to-follow-ups
07:33 < gleb> aj: I think creating issues for follow-ups might be a good idea.
07:34 < ariard> aj: well GH issue have the concern they're great to discuss but not really to sum up the state of a discussion IMO?
07:34 -!- mj_node [~mj_node@122.0.25.130] has quit [Quit: Leaving]
07:34 < ariard> specially for contributors onboarding on the state of an ongoing work and willingly to participate
07:35 < jonatack> an issue to centralise the tracking of the effects of 19858 seems like a good idea, for example
07:35 < aj> ariard: edit the first comment to maintain a summary?
07:35 < ariard> what people feeling about prepatory document like jamesob did for assumeutxo a while back ?
07:35 < jonatack> resource usage, peer rotation, the bug aj reported, etc.
07:36 < jnewbery> I personally wish that we'd not need so many follow-up PRs and just get things right the first time
07:36 < jonatack> jnewbery: agreed
07:37 < jnewbery> The attitude of "we know that there are problems with this but we'll merge it now and fix it up later" doesn't seem right for this project
07:37 < vasild> hi
07:37 < ariard> jnewbery: ideally but getting the "things right", each contributor has a different opinion because different priorities/concerns?
07:37 < jamesob> hi
07:37 < jonatack> jnewbery: that was unique to this project for me, it seems related to the review bottleneck / preservation of review
07:38 < ariard> aj: yes sound a best practice, and lighter than pinning stuff in wiki
07:39 < MarcoFalke> I think if something is moving in the wrong direction, we should hold back on merging it, but if there are issues unrelated or tangential to the change that may have existed previously or may be controversial to change, it is up to the pull author to address them or not
07:39 < jonatack> new people take a long time to become experienced reviewers, and it the meantime the increased activity structurally increases the bottleneck
07:41 < ariard> that kind of prepatory document: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal, I think amiti did the same for mempools reworks, and IMO it's pretty cool to get the rational of some proposed changes, including contra opinions
07:42 < aj> jnewbery: imo review time is the most constrained resource and we should be optimising for it; a big change and a small followup is better than multiple reworks of a big change; likewise having a big change merged quicker, so that it doesn't end up conflicting with other changes, thus requiring further re-review
07:43 < MarcoFalke> Adding a new commit to a pull that has reviews might better be done in a new pull, because it doesn't invalidate existing review . Though, if one of the commits in the pull is moving in the wrong direction, it might be better to fix it up if everyone agrees.
07:43 < ariard> MarcoFalke: obviously, if it's introducing flagrant bugs or security concerns we should hold it, but when it's code structure where people have different tolerances harder to come to a consensus...
07:44 < jnewbery> I think #16702 is a very good example of people saying "let's merge this now and fix in follow-ups". There have been at least 8 PRs to fix up the under-reviewed changes, and there are still outstanding bugs over a year later
07:44 < gribble> https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
07:44 < jonatack> aj: agree, this all relates back to that constraint
07:44 < jnewbery> That's not saving review time. It would have been much more efficient to just review it properly the first time round
07:45 < jonatack> so if we can move to loosen it, we can do better in the direction jnewbery is pointing out
07:45 < gleb> My intuitiion was that follow-ups are often less important than the core part of the PR, that's why focusing on the core part made sense.
07:46 -!- palazzovincenzo [~vincent@93-35-218-68.ip56.fastwebnet.it] has joined #bitcoin-core-dev
07:46 < luke-jr> jnewbery: +1
07:47 < jonatack> i also think that pairing 2 complementary people to work on some PRs together, pre-review, could be beneficial 
07:48 < jonatack> on an ad-hoc, informal basis, but worth exploring
07:48 < jnewbery> it was under-reviewed and broke peers.dat serialization for two releases. Reviewers and the PR author were urging the maintainers to merge now and fix issues in follow-ups. I don't understand why there was such a rush to get it merged.
07:49 < vasild> jonatack: +1
07:49 < ariard> jonatack: +1, specially on the complementarity
07:49 -!- vincenzopalazzo [~vincent@2001:b07:6474:9d49:5809:f8dd:2776:36cd] has quit [Ping timeout: 260 seconds]
07:49 < MarcoFalke> jnewbery: I also agree, but I think that means that reviewers should be shy in giving out ACKs and comfortable in giving out NACKs
07:49 < MarcoFalke> Another example is #19569
07:50 < gribble> https://github.com/bitcoin/bitcoin/issues/19569 | Enable fetching of orphan parents from wtxid peers by sipa · Pull Request #19569 · bitcoin/bitcoin · GitHub
07:50 < MarcoFalke> It was ACKed despite a known remote crasher bug
07:50 < MarcoFalke> (and merged)
07:50 < luke-jr> surprised explicit feerates hasn't been mentioned XD
07:51 < aj> MarcoFalke: huh? the remote crasher bug was known before it was merged?
07:51 < MarcoFalke> aj: Oh it wasn't? Maybe I missed that
07:52 < MarcoFalke> I presumed it was based on this comment: https://github.com/bitcoin/bitcoin/pull/19569#discussion_r462887483
07:52 < ariard> there is also a point when some PRs are approaching the upper bound of review ability like #19988, at least at some point you feel you won't provide anymore review value
07:52 < gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub
07:52 < jnewbery> I thought it was possible that there was a remote crash bug, but hadn't identified how to exploit it
07:53 < aj> MarcoFalke: i thought it was "here's a cleanup we should do in a followup" ... "oops, that cleanup fixes a crash"
07:53 < jnewbery> I offered a fix to make it safer, and the response was "let's fix it separately"
07:53 < MarcoFalke> ariard: I think it is still good to review, and maybe clarify that it is a "weaker" review 
07:54 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
07:54 < ariard> jnewbery: when you feel a PR is under-reviewed but still conceptually agree with it, I think a worthy contribution it's to point out the PR doesn't meet project standards on test coverage, code style, documentation and point to good past examples?
07:54 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
07:54 -!- kexkey [~kexkey@static-198-54-132-174.cust.tzulo.com] has joined #bitcoin-core-dev
07:55 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
07:55 < luke-jr> ariard: by the time it matters, it's merged :/
07:55 < jnewbery> ariard: those suggestions are often dismissed as 'pointless refactors' or 'nits'
07:55 < ariard> luke-jr: I mean when the PR isn't merged yet but you don't have the time to review it now but still want to inform about your opinion?
07:56 < luke-jr> ariard: we'd be posting "this is underreviewed" constantly, because we don't know when some merger might not recognise it?
07:57 < gleb> It's hard for me to imagine how one can call a suggestion to improve the safety a "pointless refactor". One is a behavior change, the other is not.
07:57 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
07:57 < ariard> jnewbery: IMO increasing project standards is something you do over time and not overnight, so yes you might have to constantly make the point until other contributors share them?
07:58 < vasild> Is anybody interested in discussing I2P connectivity?
07:58 < jonatack> vasild: sure
07:58 < ariard> luke-jr: yeah andGH sucks to clearly gather comment or identify ACK/NACKs, it could be its own feature, not regular comments?
07:58 < jonatack> (after the topic)
07:59 < vasild> ok, lets discuss after the meeting
07:59 < MarcoFalke> luke-jr: I think a good metric to see if something is close to merge is to look at the existing ACKs. If there is worry that something gets merged "underreviewed" with ACKs, you best leave a comment saying that
08:00 < jnewbery> ok, that's time folks
08:00 < ariard> thanks for participating :)
08:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
08:00 < MarcoFalke> ariard: Thanks for the topic suggestion
08:00 < jonatack> ariard, you asked yesterday how to qualify if the review bottleneck is improving
08:00 < jnewbery> Reminder: that was the last p2p meeting this year. We'll meet again on 12-Jan-2021
08:01 < jnewbery> #endmeeting
08:01 < 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
08:01 < core-meetingbot> Meeting ended Tue Dec 15 16:01:03 2020 UTC.  
08:01 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-12-15-15.01.moin.txt
08:01 -!- Lightlike [b9ff439e@185.255.67.158] has quit [Remote host closed the connection]
08:01 < jonatack> ariard: 2 reasonable rough proxies might be: open issues and pulls, and distribution of funding
08:01 < luke-jr> MarcoFalke: that might work
08:01 < jonatack> Open pull requests saw new records during the past year
08:02 < jonatack> reaching a peak in late May or early June iirc and staying roughly stable at that level since
08:02 < jonatack> Funding-wise, 2020 was a banner year, and yet at the same time a half-dozen good reviewers faced funding cuts
08:02 < ariard> jonatack: I'm a bit skeptical sometimes about pure quantiative metrics like "open issues" obviously they're likely a good sign but doesn't indicate if the underlying discussion are better, sane, productive, ...
08:02 < vasild> https://calendar.google.com/calendar/u/0/r/month/2020/12/1?cid=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ -- shows p2p meeting on Dec 29
08:02 < vasild> (I can't edit it)
08:02 < jonatack> ariard: yes, that's why i use the word proxies, but we don't have anything easy that is better
08:02 < ariard> jonatack: it's super hard and I'm still too much a newcomer to say "it was better/worse" before :)
08:03 < jonatack> An informal, very simple, one question twitter poll about the situation is still open here for a few more hours
08:03 < jonatack> https://twitter.com/jonatack/status/1338614214294966279
08:03 < jonatack> ariard: yes, I can't say if experienced and consistent review/testing are decreasing
08:03 < jonatack> or are steady or increasing but just not keeping up with the increased activity
08:03 < luke-jr> FWIW, I think the number of upstream bugs I find rebasing Knots has been increasing
08:04 < jonatack> It takes time to develop experienced reviewers on this project
08:04 < luke-jr> but it's not something I actively try to count, and perception is hard
08:04 < jonatack> so structurally it makes sense that more people participating
08:04 < jonatack> would initially cause a review crunch
08:04 < jonatack> though testing, on the other hand, can be done by relatively new people
08:04 < ariard> luke-jr: that's not good sign for sure
08:05 < luke-jr> jonatack: review, even though perhaps not experienced, is also a good way for newcomers to learn
08:05 < jonatack> so, there may to be a misalignment of incentives
08:05 < jonatack> that encourages people to not spend too much time reviewing and testing
08:05 < jonatack> e.g. I think most would agree that commits/merges, research, mailing list posts, and interviews/podcasts/outreach are more newsworthy and garner far more accolades than review and testing
08:05 < ariard> I agree you don't have to be experienced to review, and the review you're doing as a newcomer are likely to be really different and complementary
08:05 < jonatack> It's also fair to say that, with a few exceptions, new funding principally goes to those with specific project proposals
08:05 < jonatack> projects which are, naturally, prioritized by the grantees over reviewing and testing, as they will be evaluated on them
08:05 < jonatack> If then, funding, fame and glory don’t generally go to new people doing review and testing...
08:06 < jonatack> it may be fair to say that incentives are not really aligned if it is a bottleneck and we need more of it.
08:06 < MarcoFalke> I think review can also be done by new people. Obvioulsy they need more time to reach the same conclusions, but the only precondition is to have a working brain and common sense. It is not like anyone is born with a review badge on your shoulder.
08:06 < MarcoFalke> *their
08:06 < jonatack> Are review and testing then somewhat altruistic, partly done for swapping favors and keeping promises, and partly done for the greater good?
08:06 < jonatack> Is there, like open source software, an element of tragedy of the commons?
08:06 < jonatack> If yes to any of the above, I suppose it makes perfect sense if it remains the bottleneck...
08:07 < jonatack> ...and a bit like sex: more talk than actually doing it!
08:07 < jonatack> fin
08:07 < luke-jr> jonatack: one way to make funding help in this area might be to have it based on bug bounties instead ofsimple grants
08:07 < ariard> jonatack: agree on the newsworthy thing, bitcoin medias don't talk about a great ongoing review but maybe we should keep educating them?
08:07 < luke-jr> eg, reward people for finding concrete bugs in either merged or PR code
08:08 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:08 < luke-jr> (this probably has other downsides ofc, like higher overhead)
08:11 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
08:13 -!- davterra [~davterra@107.182.237.18] has joined #bitcoin-core-dev
08:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:15 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f1f2418433c9...70150824dc2c
08:15 < bitcoin-git> bitcoin/master 8c09c0c practicalswift: fuzz: Avoid time-based "non-determinism" in fuzzing harnesses by using moc...
08:15 < bitcoin-git> bitcoin/master 7015082 MarcoFalke: Merge #20437: fuzz: Avoid time-based "non-determinism" in fuzzing harnesse...
08:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:15 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20437: fuzz: Avoid time-based "non-determinism" in fuzzing harnesses by using mocked GetTime() (master...fuzzers-remove-time-based-non-determinism) https://github.com/bitcoin/bitcoin/pull/20437
08:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:16 < jamesob> Hey maintainers, the latest AU PR has 3 solid ACKs. Might be worth a look? https://github.com/bitcoin/bitcoin/pull/19806
08:18 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:32 < wumpus> jamesob:will take a look, thanks
08:33 < wumpus> jamesob: the commment about avoiding asserts with side effects probably needs to be addressed
08:37 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:38 -!- palazzovincenzo [~vincent@93-35-218-68.ip56.fastwebnet.it] has quit [Quit: Leaving]
08:38 -!- vincenzopalazzo [~vincent@2001:b07:6474:9d49:5809:f8dd:2776:36cd] has joined #bitcoin-core-dev
08:39 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:41 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
08:41 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]
08:41 < jamesob> wumpus: cool, willfix
08:42 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-dev
08:43 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Client Quit]
08:47 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:53 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/70150824dc2c...ec6149c01e6d
08:53 < bitcoin-git> bitcoin/master f7264ff Lucas Ontivero: Check if Cjdns address is valid
08:53 < bitcoin-git> bitcoin/master ec6149c Wladimir J. van der Laan: Merge #20616: Check CJDNS address is valid
08:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:53 < bitcoin-git> [bitcoin] laanwj merged pull request #20616: Check CJDNS address is valid (master...validate-cjdns-addresses) https://github.com/bitcoin/bitcoin/pull/20616
08:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:55 < andytoshi> jnewbery: oh, good idea about just waiting on listunspent (or even getbalance)
08:57 < jnewbery> I was originally going to suggest getbalance, but I thought listunspent would allow you to wait for the exact block, and you might not know exactly what balance you're waiting for
08:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:57 < bitcoin-git> [bitcoin] laanwj closed pull request #20525: Init script for debian/ubuntu (master...patch-2) https://github.com/bitcoin/bitcoin/pull/20525
08:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:58 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
08:58 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Client Quit]
08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:59 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ec6149c01e6d...a35a3466efd1
08:59 < bitcoin-git> bitcoin/master fa86217 MarcoFalke: doc: Move add relay comment in net to correct place
08:59 < bitcoin-git> bitcoin/master a35a346 MarcoFalke: Merge #20653: doc: Move addr relay comment in net to correct place
08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:59 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20653: doc: Move addr relay comment in net to correct place (master...2012-docNetAddrRelay) https://github.com/bitcoin/bitcoin/pull/20653
08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:08 < bitcoin-git> [bitcoin] sipa opened pull request #20661: Only relay torv3 addresses to addrv2-capable peers (master...202012_torv2_relay_only_addrv2) https://github.com/bitcoin/bitcoin/pull/20661
09:08 -!- Kiminuo [~mix@141.98.103.108] has joined #bitcoin-core-dev
09:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:09 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:25 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:29 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
09:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:39 < bitcoin-git> [bitcoin] lontivero opened pull request #20662: Allow setting I2P addresses (master...set-i2p) https://github.com/bitcoin/bitcoin/pull/20662
09:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:40 -!- eagless [~eagless@nova-153-092-149-207.cpe.nova.is] has joined #bitcoin-core-dev
09:45 -!- guest534543 [~mix@141.98.103.84] has joined #bitcoin-core-dev
09:48 -!- Kiminuo [~mix@141.98.103.108] has quit [Ping timeout: 260 seconds]
09:50 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-core-dev
09:51 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
09:53 -!- guest534543 [~mix@141.98.103.84] has quit [Ping timeout: 240 seconds]
10:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
10:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:03 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a35a3466efd1...8bb40d5f56c8
10:03 < bitcoin-git> bitcoin/master 44444ba MarcoFalke: fuzz: Link all targets once
10:03 < bitcoin-git> bitcoin/master fa13e1b MarcoFalke: build: Add option --enable-danger-fuzz-link-all
10:03 < bitcoin-git> bitcoin/master 8bb40d5 MarcoFalke: Merge #20560: fuzz: Link all targets once
10:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:03 < jonatack> luke-jr: sure, istm grants are essential, and donations and bounties might be complementary (if they can surmount the overhead) but probably aren't enough on their own for what needs to be done and for developer sustainability.
10:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:03 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20560: fuzz: Link all targets once (master...2012-fuzzLinkOnce) https://github.com/bitcoin/bitcoin/pull/20560
10:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:06 -!- davterra [~davterra@107.182.237.18] has quit [Ping timeout: 264 seconds]
10:07 < luke-jr> jonatack: istm?
10:07 < wumpus> provoostenator: i'm still not able to connect to your onionv3 signet seed :/
10:08 < wumpus> nice, back to one fuzz target
10:08 < jonatack> luke-jr: "it seems to me"
10:09 < jonatack> luke-jr: heh yes, it could have been read as a type of grant
10:09 < luke-jr> jonatack: depends on what the bug bounty amounts are, but sure
10:21 -!- spake [~spake@178.162.209.171] has quit [Ping timeout: 256 seconds]
10:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:21 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20663: fuzz: Leave script_assets_test_minimizer unregistered (master...2012-fuzzNoReg) https://github.com/bitcoin/bitcoin/pull/20663
10:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:21 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-lsbztgetyjllqsza] has joined #bitcoin-core-dev
10:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:24 < bitcoin-git> [bitcoin] lontivero closed pull request #20662: Allow setting I2P addresses (master...set-i2p) https://github.com/bitcoin/bitcoin/pull/20662
10:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:29 -!- lightlike [~lightlike@p200300c7ef22170074211917a47a8485.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:33 -!- belcher_ is now known as belcher
10:39 -!- alex66 [ae3b1d20@c-174-59-29-32.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
10:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:39 < bitcoin-git> [bitcoin] lontivero reopened pull request #20662: Allow setting I2P addresses (master...set-i2p) https://github.com/bitcoin/bitcoin/pull/20662
10:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:43 -!- alex66 [ae3b1d20@c-174-59-29-32.hsd1.pa.comcast.net] has quit [Remote host closed the connection]
10:45 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Quit: Pavlenex]
11:02 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
11:02 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
11:03 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
11:06 < belcher> where did the github-merge.py script go? is there an alternative used now
11:07 < harding> belcher: https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/master/github-merge.py it just changes repos
11:07 < belcher> ty
11:08 < harding> changed *
11:08 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
11:09 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Client Quit]
11:10 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
11:11 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Client Quit]
11:17 -!- Kiminuo [~mix@141.98.103.124] has quit [Ping timeout: 256 seconds]
11:21 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
11:21 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
11:27 -!- jeremyb [~jeremyb@84.39.117.57] has joined #bitcoin-core-dev
11:30 < wumpus> yep
11:37 -!- guaj0 [~guaj0@231.red-95-120-196.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
11:40 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
11:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:41 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #20664: Add scanblockfilters RPC call (master...2020/12/filterblocks_rpc) https://github.com/bitcoin/bitcoin/pull/20664
11:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:44 < bitcoin-git> [bitcoin] gruve-p opened pull request #20665: Build: update clang patch url and hash (master...master) https://github.com/bitcoin/bitcoin/pull/20665
11:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:46 < dhruvm> CI re-run please? https://cirrus-ci.com/task/5858449189765120
11:47 < sipa> dhruvm: done
11:53 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
11:54 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
12:00 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
12:02 < dhruvm> 🙏🙏🏽
12:02 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
12:03 < provoostenator> wumpus: it's the same machine that I use for DNS seed crawling. Perhaps its incessant hammering of the Tor network is causing the flakiness.
12:03 < provoostenator> I might move the Signet seed node elsewhere.
12:05 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-core-dev
12:07 < provoostenator> Indeed curling the blockstream explorer v3 URL is also unresponsive.
12:07 < provoostenator> (from that machine)
12:08 -!- guaj0 [~guaj0@231.red-95-120-196.dynamicip.rima-tde.net] has quit [Quit: Leaving]
12:12 < dhruvm> jonatack: Your comment about grant-seekers prioritizing projects over testing/review sounds right. One potential way to affect change: Core devs could get together and let it be known that they will give letters of recommendation for grant committees and will overweight review and testing.
12:18 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
12:20 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]
12:20 -!- Pavlenex [~Thunderbi@185.103.110.235] has joined #bitcoin-core-dev
12:21 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
12:21 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-dev
12:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
12:31 < wumpus> provoostenator: i've seen this problem as well with more or less busy tor services, usually restarting the daemon works, at least for a while
12:32 < provoostenator> I just moved it to a different machine,  it should be reachable now
12:32 < wumpus> oh it succeeds now !
12:33 < provoostenator> Hopefully it stays that way.  This new machine doesn't do antying tor-intensive.
12:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:39 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8bb40d5f56c8...d9a4738c9d3d
12:39 < bitcoin-git> bitcoin/master 3e6657a Sjors Provoost: Move signet onion seed from v2 to v3
12:39 < bitcoin-git> bitcoin/master d9a4738 Wladimir J. van der Laan: Merge #20660: Move signet onion seed from v2 to v3
12:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:39 < bitcoin-git> [bitcoin] laanwj merged pull request #20660: Move signet onion seed from v2 to v3 (master...2020/12/signet-v3-onion) https://github.com/bitcoin/bitcoin/pull/20660
12:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
12:45 < wumpus> one less v2 onion in the source code :)
12:46 < sipa> peeling them off, one by one
12:46 < wumpus> yess
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:50 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d9a4738c9d3d...c434e2cca918
12:50 < bitcoin-git> bitcoin/master faf2c6e MarcoFalke: cirrus: Schedule one task with paid credits for faster CI feedback
12:50 < bitcoin-git> bitcoin/master c434e2c Wladimir J. van der Laan: Merge #20615: cirrus: Schedule one task with paid credits for faster CI fe...
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:50 < bitcoin-git> [bitcoin] laanwj merged pull request #20615: cirrus: Schedule one task with paid credits for faster CI feedback (master...2012-ciFasterFeedback) https://github.com/bitcoin/bitcoin/pull/20615
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:53 -!- Pavlenex [~Thunderbi@185.103.110.235] has quit [Quit: Pavlenex]
12:56 -!- lontivero [~lontivero@186.183.3.236] has quit [Ping timeout: 256 seconds]
12:56 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Quit: Leaving]
13:00 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #bitcoin-core-dev
13:05 < jonatack> dhruvm: sure, sgtm. partly i reckon that even when grantors eyes don't glaze over at the importance of review & testing (and understanding of that does indeed seem to be improving from what I hear), evaluating grantee performance on that remains a challenge for them as they have to rely on peer feedback. It might be a bit easier for them to evaluate the delivery of a specific project, and
13:06 < jonatack> to sell/market it internally to stakeholders to justify continued open source grant funding.
13:12 < jonatack> dhruvm: that said, it's only speculation on my part. my grantor specifically asked that i keep reviewing if supported--they get it.
13:14 < wumpus> even if the eventual goal is do deliver a project, reviewing other people's changes (especially to the part of the code which is their interest) will likely make them a better contributor in the first place
13:14 < jonatack> yess
13:16 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
13:33 < dhruvm> yeah - so the core of the issue is that it's hard for the grantors to evaluate performance. that is something core devs can develop a system around?
13:34 < dhruvm> kinda like peer performance reviews at companies
13:35 < dhruvm> they face similar challenges with hiring for example. engineers don't like interviewing but it is crucial in a fast growth situation.
13:36 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
13:38 < dhruvm> i've had jobs where contribution to hiring was as important as new launches for those reviews
13:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:41 -!- miketwenty1 [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
13:44 < jonatack> dhruvm: hiring: yes, in my previous life i sometimes brought the dev team for the 6-12 month long projects, every project was like a band reunion
13:45 -!- miketwen_ [~miketwent@ec2-3-216-176-187.compute-1.amazonaws.com] has quit [Ping timeout: 256 seconds]
13:45 < jonatack> dhruvm: evaluation does seem to be a key issue, and there are some initiatives afoot to work on this 
13:47 -!- Kiminuo [~mix@141.98.103.124] has quit [Ping timeout: 256 seconds]
13:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:47 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c434e2cca918...dff0f6f753ea
13:47 < bitcoin-git> bitcoin/master fade619 MarcoFalke: Move TX_MAX_STANDARD_VERSION to policy
13:47 < bitcoin-git> bitcoin/master dff0f6f Wladimir J. van der Laan: Merge #20611: Move TX_MAX_STANDARD_VERSION to policy
13:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:47 < bitcoin-git> [bitcoin] laanwj merged pull request #20611: Move TX_MAX_STANDARD_VERSION to policy (master...2012-mvTxStandardVersion) https://github.com/bitcoin/bitcoin/pull/20611
13:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:51 -!- guaj0 [~guaj0@31.221.210.108] has joined #bitcoin-core-dev
13:57 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving]
13:58 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
13:58 -!- peterrizzo_ [~peterrizz@ool-44c18924.dyn.optonline.net] has joined #bitcoin-core-dev
14:17 -!- miketwen_ [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
14:18 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 260 seconds]
14:19 -!- jonatack [~jon@213.152.162.99] has joined #bitcoin-core-dev
14:21 -!- miketwenty1 [~miketwent@136.55.84.49] has quit [Ping timeout: 240 seconds]
14:23 -!- miketwen_ [~miketwent@136.55.84.49] has quit [Ping timeout: 240 seconds]
14:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:23 < bitcoin-git> [gui] luke-jr opened pull request #153: GUI: Define MAX_DIGITS_BTC for magic number in BitcoinUnits::format (master...const_max_digits) https://github.com/bitcoin-core/gui/pull/153
14:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:25 -!- miketwenty1 [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
14:32 -!- guaj0 [~guaj0@31.221.210.108] has quit [Quit: Leaving]
14:45 -!- flag [~flag@net-93-66-71-105.cust.vodafonedsl.it] has quit [Ping timeout: 264 seconds]
14:46 -!- rex4539 [~rex4539@8.40.29.10] has joined #bitcoin-core-dev
14:48 -!- miketwenty1 [~miketwent@136.55.84.49] has quit [Read error: Connection reset by peer]
14:48 -!- miketwen_ [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
14:50 -!- rex4539 [~rex4539@8.40.29.10] has quit [Client Quit]
14:52 -!- davterra [~davterra@107.182.237.19] has joined #bitcoin-core-dev
14:56 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:57 -!- flag [~flag@net-93-66-71-105.cust.vodafonedsl.it] has joined #bitcoin-core-dev
14:58 -!- guaj0 [~guaj0@231.red-95-120-196.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
15:01 -!- guaj0 [~guaj0@231.red-95-120-196.dynamicip.rima-tde.net] has quit [Client Quit]
15:28 -!- Asbestos_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has quit [Ping timeout: 260 seconds]
15:39 -!- instagibbs [~greg@061093103011.ctinets.com] has joined #bitcoin-core-dev
15:44 < instagibbs> apologies if this gets double-posted, my irc setup being wonky: I can say from a bit of experience in the "grant business" that there is a lot of pressure(rightly so) to not influence "what" a person is working on, and that "inability to evaluate a reviewer" has not been a reason to deny grants(IIRC no one actually applied where their top line was "review"). in other words, if someone wants to get a grant to do review, they have to 
15:44 < instagibbs> submit an application :)
15:44 < instagibbs> if we have a dearth of review because of *funding* this is fixable. I suspect not.
15:45 < instagibbs> s/fixable/easily fixable/
15:46 < luke-jr> instagibbs: …
15:46 < instagibbs> luke-jr, !!!
15:46 < luke-jr> instagibbs: well, it might not add review, but it could keep from losing my reviewing if I got funding <.<
15:47 < luke-jr> I hate saying it like that, but I can't keep doing this unfunded forever XD
15:47 < instagibbs> (Can only speak to the one grant program I'm involved in)
15:48 < instagibbs> I suspect in general it's "we need to motivate coders to become reviewers" and "we need new contributors" 
15:49 < instagibbs> Also, people can still bug me for review, I'm not on IRC much anymore(life stuff) but if you bug me via email I will likely do it :)
15:49 < luke-jr> yes, I suspect that's part of it
15:50 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
15:56 -!- palazzovincenzo [~vincent@2001:b07:6474:9d49:5809:f8dd:2776:36cd] has joined #bitcoin-core-dev
15:56 -!- vincenzopalazzo [~vincent@2001:b07:6474:9d49:5809:f8dd:2776:36cd] has quit [Ping timeout: 260 seconds]
15:58 -!- vincenzopalazzo [~vincent@93-35-218-68.ip56.fastwebnet.it] has joined #bitcoin-core-dev
16:00 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has joined #bitcoin-core-dev
16:00 -!- palazzovincenzo [~vincent@2001:b07:6474:9d49:5809:f8dd:2776:36cd] has quit [Ping timeout: 260 seconds]
16:02 -!- miketwen_ [~miketwent@136.55.84.49] has quit [Read error: Connection reset by peer]
16:02 -!- miketwenty1 [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
16:05 -!- eagless [~eagless@nova-153-092-149-207.cpe.nova.is] has quit [Quit: Leaving]
16:05 -!- guaj0 [~guaj0@231.red-95-120-196.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
16:07 -!- palazzovincenzo [~vincent@93-35-218-68.ip56.fastwebnet.it] has joined #bitcoin-core-dev
16:07 -!- palazzovincenzo [~vincent@93-35-218-68.ip56.fastwebnet.it] has quit [Remote host closed the connection]
16:08 -!- vincenzopalazzo [~vincent@93-35-218-68.ip56.fastwebnet.it] has quit [Ping timeout: 268 seconds]
16:09 -!- guaj0 [~guaj0@231.red-95-120-196.dynamicip.rima-tde.net] has quit [Client Quit]
16:18 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 256 seconds]
16:28 -!- iamgr00t_ is now known as iamgr00t
16:28 -!- lontivero [~lontivero@186.141.228.160] has joined #bitcoin-core-dev
16:30 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has joined #bitcoin-core-dev
16:35 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has quit [Ping timeout: 260 seconds]
16:38 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:cecf:a55b:90cf:1ae1:4d7b] has joined #bitcoin-core-dev
17:06 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-witaeypfsoxnjlkc] has quit [Ping timeout: 268 seconds]
17:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:23 -!- lightlike [~lightlike@p200300c7ef22170074211917a47a8485.dip0.t-ipconnect.de] has quit [Quit: Leaving]
17:34 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
17:43 -!- lontivero [~lontivero@186.141.228.160] has quit [Ping timeout: 256 seconds]
17:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:55 -!- tryphe_ is now known as tryphe
17:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
18:00 -!- lontivero [~lontivero@186.183.3.236] has joined #bitcoin-core-dev
18:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
18:10 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
18:19 -!- dermoth [~dermoth@unaffiliated/dermoth] has quit [Read error: Connection reset by peer]
18:19 -!- dermoth [~dermoth@unaffiliated/dermoth] has joined #bitcoin-core-dev
18:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:29 -!- lontivero [~lontivero@186.183.3.236] has quit [Ping timeout: 260 seconds]
18:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:34 < bitcoin-git> [bitcoin] adamjonas opened pull request #20668: doc: warn that incoming conns are unlikely when not using default ports (master...121520-non-standard-port-doc) https://github.com/bitcoin/bitcoin/pull/20668
18:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:37 < fanquake> wumpus / achow: do you have the links to any of the codesigning/inspection tools you wrote handy
18:39 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-boajzynatzrltwgx] has quit [Ping timeout: 268 seconds]
18:39 < achow101> fanquake: https://gist.github.com/achow101/fef2415d99965de66ac083b54b83df6e is the tool we ended up with. I'm writing a full codesigning and inspection tool at https://github.com/achow101/signapple
18:40 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-gyzoapdcugmmdwow] has joined #bitcoin-core-dev
18:40 < fanquake> achow: thanks
18:40 < sipa> achow101: how is that going?
18:41 < fanquake> I see lots of blobs
18:41 < achow101> sipa: I've reversed engineered the internal requirements thing. It's a mini scripting language with opcodes and stuff
18:41 < achow101> considered writing an AST representation of it but decided that was too much effort
18:41 < sipa> sounds like fun & an amazing timesink :)
18:42 -!- lontivero [~lontivero@186.183.48.29] has joined #bitcoin-core-dev
18:42 < achow101> I think I can have it sign in a few days
18:42 < fanquake> achow101: is the goal here to replace codesign/codesign_allocate ?
18:42 < achow101> it fully verifies, including stuff that we don't currently deal with in our signing, like whatever entitlements are
18:42 < achow101> fanquake: yes
18:43 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-rnzdvvnshecmqbvf] has joined #bitcoin-core-dev
19:00 < sipa> p
19:00 < fanquake> q
19:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
19:16 -!- peterrizzo_ [~peterrizz@ool-44c18924.dyn.optonline.net] has quit [Quit: peterrizzo_]
19:16 -!- kexkey [~kexkey@static-198-54-132-174.cust.tzulo.com] has quit [Quit: Do, don't don't]
19:39 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 256 seconds]
19:45 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
19:45 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
19:45 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
19:51 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 240 seconds]
19:52 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
19:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:27 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
20:27 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
20:27 -!- miketwenty1 [~miketwent@136.55.84.49] has quit [Remote host closed the connection]
20:32 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz]
20:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:59 -!- lontivero [~lontivero@186.183.48.29] has quit [Ping timeout: 240 seconds]
22:05 -!- jonatack [~jon@213.152.162.99] has quit [Read error: Connection reset by peer]
22:11 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-dev
22:27 -!- jeremyb [~jeremyb@84.39.117.57] has quit [Remote host closed the connection]
22:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:38 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20669: [0.21] final rc4 backports (0.21...2012-rc4) https://github.com/bitcoin/bitcoin/pull/20669
22:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:43 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
22:44 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]
23:00 < wumpus> from what i understood the entitlements are mostly used on iOS where it describes extra privileges of the application
23:01 < fanquake> yea we'd only need them on macOS if we wanted to use things like NFC, location services, apple pay etc
23:03 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
23:03 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]
23:07 < sipa> apple pay integration, hmm!
23:10 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-core-dev
23:17 -!- jackgassett [~jackgasse@84.39.117.57] has joined #bitcoin-core-dev
23:23 < jonasschnelli> achow101: nice work!
23:26 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]
23:30 < wumpus> yea desktop OSes tend to be much more lenient with regard to application permissions, though i was surprised recently that flatpak has a fine-grained system for controlling what an application is allowed to access, even some capability based thing to deny access to the entire home directory but allow access only to files selected by the user, kind of clever
23:32 < jonasschnelli> Yeah. I like this feature in modern macOS. Each application has to ask permission to access certain directories of the filesystem. Same for camera access, location, etc..
23:32 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
23:32 < jonasschnelli> On the other hand,.. it comes with a lot of control handed over to Apple (unnecessary). Like the whole notarization process.
23:33 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
23:37 < wumpus> that's one issue with any security feature in proprietary OSes, they always ends up as a way the vendor can assert control, even if the feature itself was a good idea
23:39 < wumpus> they always want to be the one controlling the locks and that makes it more like a jail (as Bunnie would say)
23:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
23:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
--- Log closed Wed Dec 16 00:00:48 2020