19:00:12 <laanwj> #startmeeting 
19:00:13 <core-meetingbot> Meeting started Thu Dec  2 19:00:12 2021 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:13 <core-meetingbot> Available commands: action commands idea info link nick
19:00:29 <hebasto> hi
19:00:33 <b10c> hi
19:00:41 <kvaciral[m]> hi
19:00:43 <sipa> hi
19:01:01 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard 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 moneyball
19:01:03 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:24 <laanwj> one proposedmeetingtopic: Warn when we have only _old_ peers? (b10c)
19:01:31 <lightlike> hi
19:01:58 <jamesob> hi
19:02:15 <laanwj> any last minute topics?
19:03:15 <laanwj> #topic High priority for review
19:03:15 <core-meetingbot> topic: High priority for review
19:03:18 <meshcollider> hi
19:03:43 <laanwj> https://github.com/bitcoin/bitcoin/projects/8  9 blockers, 1 chasing concept ACK
19:04:09 <laanwj> anything to add/remove or that is almost ready for merge?
19:04:16 <MarcoFalke> can i haz #19499 pls ?
19:04:18 <gribble> https://github.com/bitcoin/bitcoin/issues/19499 | p2p: Make timeout mockable and type safe, speed up test by MarcoFalke · Pull Request #19499 · bitcoin/bitcoin · GitHub
19:04:42 <jamesob> MarcoFalke: oh cool, will review
19:05:01 <laanwj> MarcoFalke: added
19:05:09 <MarcoFalke> thx
19:06:51 <laanwj> would it make sense to add  #23443? it's a blocker for erlay and the next step
19:06:55 <gribble> https://github.com/bitcoin/bitcoin/issues/23443 | p2p: Erlay support signaling by naumenkogs · Pull Request #23443 · bitcoin/bitcoin · GitHub
19:07:21 <sipa> won't hurt to add it i guess
19:08:01 <laanwj> ok, will do
19:09:08 <laanwj> does anyone have other suggestions? or wants to discuss an existing high prio PR?
19:10:03 <laanwj> if not, let's move on to the next topic
19:10:12 <laanwj> #topic Warn when we have only _old_ peers? (b10c)
19:10:12 <core-meetingbot> topic: Warn when we have only _old_ peers? (b10c)
19:10:25 <b10c> I've posted a few comments about why F2Pool initially didn't include P2TR spends in their blocks to the ML: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019608.html
19:10:32 <b10c> TLDR: buggy patches to their peer selection. An unmaintained heuristic filtered newer Bitcoin Core peers. But, (IMO) unpublished patches are out of scope for the Bitcoin Core project.
19:10:40 <b10c> However, with currently only ~50% of nodes upgraded, it could still be relevant to warn node operators about e.g. only being connected to peers old that don't relay P2TR spends.
19:10:58 <sipa> a first question is: how would this even be detectable
19:11:03 <b10c> Something like this could be a feature we want before the next soft-fork affecting transaction relay.
19:11:17 <b10c> sipa: right
19:11:25 <b10c> Bump PROTOCOL_VERSION for soft-fork tx relay? service flag e.g. TAPROOT_RELAY? Flag in the version message indicate soft-fork readiness?
19:11:38 <sipa> but this isn't about softforks
19:11:45 <sipa> it's about any change in relay policy
19:12:20 <sipa> though, at least the past few years, the only invasive changes to relay policy (in bitcoin core at least) have been due to softforks, i think
19:13:27 <b10c> and the next question would be: How to warn node operators (besides logging to debug.log)? getnodealerts/getnodewarnings RPC?
19:14:00 <sipa> i think the best approach (assuming there was a way to detect it), would be to add more outgoing connections and/or rotate them faster
19:14:19 <laanwj> we've become kind fo careful about warnings that are not relevant to most users
19:14:30 <sipa> we kind of do something like that when we believe we're only connected to consensus-incompatible peers already
19:15:07 <sipa> but detecting is kind of ugly, i think... because it goes to concerns like should we try to inform our peers about the entirety of our relay policy?
19:15:27 <sipa> and i'm not sure the problem is big enough of a concern to even get into that
19:16:10 <sipa> relay policy is just policy, after all
19:16:30 <b10c> hmm agree, if it would only be for soft-forks maybe a simple flag would be enough. but gets messy with the entirety of policy
19:16:47 <lightlike> has this also been an issue in normal circumstances? The mailing list post talks about some artifical addnode scenario, extra automtic outbounds wouldn't help with that.
19:16:54 <laanwj> i do think some heuristic would make sense when broadcasting, e.g. when you broadcast a transaction and no peer relays it back to you
19:17:09 <sipa> laanwj: that would be useful!
19:17:28 <sipa> though, that may not be sufficient for this case even
19:17:40 <b10c> that would help in the sender case, not in the miner case
19:17:44 <sipa> as it would only make the original tx broadcasters notice, not intermediaries
19:18:24 <b10c> lightlike: I haven't heard about any other case
19:19:18 <sipa> given that the first P2TR spends actually reached miners fine within a few blocks kind of shows there were no relay problems (that we know of)
19:19:40 <sipa> and if it's just unfortunate local configuration on the miners side, i don't think this would do much, given what lightlike said
19:19:49 <laanwj> peers witholding certain transactions from you is a subset of the general eclipse problem
19:20:48 <laanwj> if you're worried about that, especially as a miner you'd likely want to make sure you connect to a few trusted peers (preferably over overlay networks)
19:21:24 <sipa> b10c: oh i see, your assumption was that it would be warning operators, not just trying to fix things automatically
19:21:42 <sipa> i think the only reliable way to warn operators is by shutting down...
19:22:35 <b10c> that is definitely reliable for a mining pool, but also a DoS vector
19:22:45 <sipa> indeed
19:22:52 <laanwj> shutting down based on a heuristic about connected peers seems kind of drastic
19:23:02 <sipa> yes, i only mentioned it in jest
19:23:16 <laanwj> you can do that of course (a watchdog kind of script), but i see no reason to build that into bitcoin core
19:23:54 <b10c> one idea was a RPC interface (e.g. getnodewarnings) to hook into from your monitoring stack
19:24:09 <b10c> to at least have something well defined
19:24:16 <laanwj> but if you have monitoring software, why not call getpeerinfo
19:24:31 <MarcoFalke> there is already getblockchaininfo()[warnings]
19:24:39 <sipa> yeah...
19:24:43 <laanwj> i suppose all the information you need to decide about node versions is there
19:25:58 <laanwj> it's never more than a heuristic, untrusted nodes can lie about versions, version bits, etc
19:26:14 <laanwj> service bits*
19:27:14 <b10c> cool, thanks! This discussion was helpful for me. Maybe a heuristic for a sender if his transaction got relayed back to him... Everything else might be to ambitious and messy
19:27:37 <sipa> yeah i don't really have any good ideas
19:27:49 <b10c> not relayed*
19:27:50 <laanwj> (which is also what makes it somewhat scary as a built-in warning; i remember the spurious new-unsupported-version warnings with the block version bits when miners started using them for... other things)
19:27:56 <laanwj> right
19:28:58 <laanwj> any other topics?
19:30:16 <laanwj> closing the meeting, thanks everyone for attending
19:30:20 <laanwj> #endmeeting