15:00:13 <jnewbery> #startmeeting
15:00:13 <lightningbot> Meeting started Tue Aug 25 15:00:13 2020 UTC.  The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:21 <jonatack> hi
15:00:23 <hebasto> hi
15:00:24 <sdaftuar> hi
15:00:24 <troygiorshev> hi
15:00:26 <amiti> hi
15:00:28 <ajonas> hi
15:00:29 <fanquake> hi
15:00:52 <gzhao408> hi
15:01:05 <jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
15:01:11 <MarcoFalke> hi
15:01:11 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
15:01:26 <jnewbery> hi folks. Welcome to p2p meeting 2!
15:01:36 <sipa> hi
15:01:40 <jnewbery> #topic priority/focus
15:01:54 <jnewbery> Does anyone have any updates that they want to share since last week?
15:02:05 <jonatack> y
15:02:08 <jnewbery> feel free to jump in
15:02:24 <jnewbery> s/last week/last meeting/
15:02:27 <jonatack> My prios were BIP155, BIP324, and BIP325 implementation PRs, and they seem to be moving forward.
15:02:30 <hebasto> just after jon :)
15:02:35 <ariard> hi
15:02:37 <jonatack> BIP155 addrv2: #19628 has been receiving review from sipa, elichai, ryanofsky, kallewoof, sipsorceryand myself, and now has 4 ACKs; vasild is deferring further (minor) changes to the PR in order to preserve existing review, but there's no reason to not review it
15:02:42 <gribble> https://github.com/bitcoin/bitcoin/issues/19628 | net: change CNetAddr::ip to have flexible size by vasild · Pull Request #19628 · bitcoin/bitcoin · GitHub
15:02:53 <jonatack> it seems to be close
15:02:58 <jonatack> BIP325 signet: #18267 has been through a few more rounds of review and seems to be getting close, with recent review by fjahr, pinheadz, MarcoFalke, instagibbs, and myself
15:03:01 <gribble> https://github.com/bitcoin/bitcoin/issues/18267 | BIP-325: Signet [consensus] by kallewoof · Pull Request #18267 · bitcoin/bitcoin · GitHub
15:03:09 <jonatack> (sorry if that isn't p2p)
15:03:12 <aj> hi
15:03:14 <jonatack> BIP324 v2 p2p encrypted message transport protocol: right after the last p2p meeting, jonasschnelli rebased and updated #18242 (changes only used in tests for now) and I've begun re-reviewing it along with the BIP, which has some open questions.
15:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
15:03:26 <jonatack> The BIP had received no new feedback since mid-June and the latest review by ariard, elichai, and realorrandom, but Lloyd Fournier just wrote a detailed comment yesterday, which I plan to go through asap: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#gistcomment-3428675
15:03:29 <sipa> unfortunately no; i haven't gotten to rebasing/updating the tx overhaul, by being distracted on taproot and a few generic secp256k1 issues; i did reviews for 19628 though; happy to see that moving along
15:03:53 <jonatack> I encourage people to review BIP 324 and the PR 18242.
15:04:20 <nehan> hi
15:04:23 <jonatack> 19731 was merged yesterday, which allows some interesting possibilities for eviction tests and I have added those columns into my dev branch of cli -netinfo
15:04:31 <jonatack> 19643 achieved a pretty massive rough consensus with ~9/10 Concept/Approach ACKs and 6 full tested ACKs by wumpus, 0xB10C, fjahr, vasild, practicalswift and pinheadz.
15:04:39 <jonatack> It's an extremely useful tool for anyone rrrrunning a node, particularly developerrrs and p2p reviewerrrs, and is completely encapsulated in a single class in bitcoin-cli.cpp that is both easy to maintain and easy to rrrip out in 2 minutes if no longer wanted
15:04:52 <jonatack> finnaly
15:04:52 <sipa> jonatack: yeah, i need to respond to llfourn's comments
15:04:53 <jonatack> 19610 is a net processing pure refactoring and simplification with jnewbery, that splits AlreadyHave() up into AlreadyHaveTx() and AlreadyHaveBlock() since they are now two totally separate concepts; the block and transaction paths have drifted apart sufficiently that it no longer makes sense to have a common function there. The PR also simplifies CInv::type and INV/TX processing code.
15:04:55 <jonatack> Thanks to fjahr, jnewbery, and vasild who have reviewed it so far! Review welcome.
15:05:04 <jonatack> that's it for me :p
15:05:07 <vasild> hi
15:05:46 <ajonas> I've been trying to keep track of the #18044 clean-ups.
15:05:51 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
15:05:56 <ajonas> I've checked in with jnewbery and amiti on them. sipa has some he's said he's going to do. instagibbs has already pushed a test. jeremy has a few that he's been discussing with amiti as well.
15:06:21 <ajonas> and then there are the backports
15:07:02 <hebasto> my prios are #17785 and #17428
15:07:05 <gribble> https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto · Pull Request #17785 · bitcoin/bitcoin · GitHub
15:07:08 <gribble> https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
15:07:17 <fanquake> I don't think there's any rush to do the backports until any followup discussion changes/have been finalized. Might as well backport all that's needed at once.
15:07:23 <sipa> ajonas: i think my followup is dome already (#19569)
15:07:26 <gribble> https://github.com/bitcoin/bitcoin/issues/19569 | Enable fetching of orphan parents from wtxid peers by sipa · Pull Request #19569 · bitcoin/bitcoin · GitHub
15:07:35 <ariard> sipa: what was llfourn main proposal of change for bip324? He didn't propose to MAC the length field, so no BIP change
15:07:48 <ajonas> sipa: I'll take a look. Thanks.
15:07:56 <MarcoFalke> The one to 0.19 should be ready, right? No other p2p backports are planned for that release and we might as well ship 0.19 after that backport
15:07:59 <ariard> and the DoS concern are more theoritical, given you have easier alternatives
15:08:11 <sipa> ariard: no changes, just commentary, iirc - but i need to go through it in more detail
15:08:58 <sdaftuar> i've been thinking about small topology improvements, specifically picking up the main idea of #16859
15:08:59 <gribble> https://github.com/bitcoin/bitcoin/issues/16859 | Syncing headers with feeler-peers · Issue #16859 · bitcoin/bitcoin · GitHub
15:09:16 <sdaftuar> well, that's only sort of a topology improvement, depending on implementation, actually
15:09:39 <sdaftuar> the main idea is to sync headers with more peers, and potentially replace peers with new ones as well
15:09:46 <sdaftuar> hopefully PR to come soon-ish
15:10:25 <sipa> are we eventually just going to split up all functionality, and have header-peers, block-peers, tx-peers, addr-peers? :)
15:10:46 <ariard> we might learn headers from feelers, but are we going to actively maintain connections to them if we learn about a potential better chain?
15:10:55 <aj> sipa: separating addr-peers sounds weird, but all the rest of it...
15:11:01 <sdaftuar> i don't know! :)  i have two implementations of that idea that i'm playing with, one where i introduce a new peer type (headers-sync-peer) which gets quickly dropped
15:11:05 <ariard> like upgrading them to block-peers and evvicting one in consequence if max outboounds reach
15:11:13 <sdaftuar> and the other where i treat it as an extra block-relay-only peer that can evict another block-relay peer
15:11:26 <aj> sipa: that segues to what i've been working on which is supporting "regular" peers and "taproot-enabled" (and "anyprevout-enabled") peers for signet, indicated via service flags...
15:12:28 <ariard> right, for the headers-sync-peer variant, you can store headers with addrs, and if we stale tip randomly pick up a better-chain-known-addr, open a connection with them
15:12:36 <ariard> though likely more compelx of implementation
15:13:19 <sipa> aj: just so that txn would propagate well?
15:13:30 <amiti> sdaftuar: you had mentioned thinking about a way to distinguish incoming block-relay-only connections. I’m guessing this has something to do with the feature negotiation topic on the mailing list? what are your current thoughts?
15:13:48 <ariard> maybe not store headers, just mark them as known-as-useful-peers
15:13:57 <aj> sipa: s/well/at all/, yeah
15:14:11 <sdaftuar> oh right, now that i have clarity on how to propose new feature negotiation, yeah i'm thinking about a simple way to negotiate block-relay only connections at peer connection time, so that both sides of a connection know they can devote less resources to each other
15:14:18 <sdaftuar> which is mostly a per-peer memory savings
15:14:51 <sdaftuar> and then hopefully we can increase the number of inbounds (specifically carve out extra inbound slots for block-relay peers)
15:15:02 <sdaftuar> and then increase the number of block-relay outbound connections we make too
15:15:28 <sdaftuar> so i'm planning to pick that up as well in the near term
15:15:46 <jnewbery> > now that i have clarity on how to propose new feature negotiation
15:15:50 <jnewbery> ^ it wasn't clear to me what the outcome of the mailing list discussion was. What are you proposing?
15:15:52 <sipa> aj: for segwit, this preferential peering was critical, as blocks wouldn't propagate from old modes to new ones... for the things you're talking about it's just about transactions
15:15:57 <fanquake> related #19723
15:15:59 <gribble> https://github.com/bitcoin/bitcoin/issues/19723 | Ignore unknown messages before VERACK by sdaftuar · Pull Request #19723 · bitcoin/bitcoin · GitHub
15:16:00 <sdaftuar> jnewbery: just accompany new features with a protocol version bump
15:16:10 <sdaftuar> but otherwise copy what has been done before
15:16:33 <sdaftuar> seems to me that path is basically unobjectionable
15:17:02 <sipa> it works okayish
15:17:10 <jnewbery> forcing protocol changes to be serial seems not as good as being able to opt in to different features
15:17:27 <sdaftuar> i think we can deal with that when we actually get protocol version number conflicts?
15:17:31 <sdaftuar> seems like it doesn't happen in practce
15:17:34 <aj> sipa: yeah, not much fun if your transactions don't propogate though
15:17:37 <sipa> sdaftuar: fair
15:18:00 <sdaftuar> and i don't think we can force other implementations to adopt anything generic (like i proposed)
15:18:06 <sdaftuar> so i think it's easy for now to accommodate those preferences
15:18:21 <aj> sipa: atm i'm telling it once you've got 50% peers connected, only add more outbounds if it improves your tx connectivity
15:18:48 <sipa> aj: yeah, and with a better separation between block and tx connections (or block-only and full connections) it may be possible to apply such peering only on the tx-carrying ones
15:19:18 <sdaftuar> hm, we've not historically used service bits for tx-relay properties right?
15:19:24 <aj> sipa: yep. blocks-only happens after tx-carrying ones atm; which is maybe backwards?
15:19:41 <sipa> sdaftuar: indeed
15:19:51 <sipa> i'm a bit hesitant about that...
15:20:14 <sdaftuar> we don't have a good framework for thinking about transaction propagation imo
15:20:44 <ariard> right, and that's something we need for higher layer :)
15:21:14 <amiti> sdaftuar: care to elaborate? what would a good framework look like? or, what is something we do have a good framework for thinking about?
15:21:15 <aj> is there anything that'd make more sense than service flags? i think you want something that's in addrman, in case there's 5000 nodes, and only 5 of them support the feature you want
15:21:17 <sipa> aj: also, this isn'ta actually specific to softforks, but to policy cjangs
15:21:27 <sdaftuar> sipa: exactly
15:21:38 <aj> sipa: yep
15:21:43 <sdaftuar> but i think there is something to be said for splitting up policy issues into things you can deal with, and things that are hopeless?
15:21:51 <sipa> so far we haven't assumed we can reasom about peer's tx policies
15:21:52 <sdaftuar> i don';t know
15:21:54 <ariard> at least there is a difference between propagation validity and ensuring your tx-propagation paths aren't intersected by malicous/buggy peers
15:22:29 <sipa> arguably, we do already, in the form of feefilter
15:22:43 <sipa> that is effectively tellings peer part of our relay policy
15:23:22 <sipa> with automatic tx rebroadcast there may be slightly less need for this
15:23:26 <sdaftuar> there are so many things that can go wrong with respect to transactions you have not propagating well
15:23:28 <aj> perhaps it should be an entirely separate addressbook, and you have to look up via a separate seed, rather than flags in the existing address book?
15:24:00 <sipa> aj: i feel it's a can of worms, trying to do this well
15:24:01 <ariard> policy has to be hardcoded in higher layers, like minimum transaction size, unless you assume you higher stack to fetch your node to learn peer policies negotiated
15:24:03 <sdaftuar> automatic tx rebroadcast + tx-relay-peer rotation might be the most robust thing we can do?
15:24:09 <ariard> at least a subset
15:25:04 <sipa> plus the philosophical issue that it means assumptions on being to rely on (claimed/standardized) policy
15:25:07 <aj> sipa: sure. i only really care about doing it adequately at this point :)
15:25:24 <sipa> so, eh
15:25:33 <sipa> why hasn't this historically been needed?
15:25:39 <sdaftuar> :)
15:25:46 <ariard> sipa: I agree that's a philosophical issue but that was implicetely part of any payment channel design with timelocks
15:25:54 <aj> sipa: because everyone upgrades before the policy change activates?
15:26:06 <sipa> aj: right
15:26:07 <aj> sipa: then no one transacts with the changed policy for a while anyway
15:26:10 <instagibbs> none of your peers accepting a softfork policy may tell you something too :)
15:26:12 <ariard> wait for some LN implementation being broken for forgetting some policy check
15:26:25 <sipa> ariard: i feel that's a mistake, tbh
15:26:57 <ariard> sipa: ofc but the fact that they are not well-documented contribute to this, like no proper toolchain to test them in separation
15:27:49 <ariard> and you have the issue of a time-sensitive A propagating wrt to policy set X but not with policy set Y and your full-node being only connected to peers Y
15:27:58 <ariard> time-sensitive tx A
15:28:22 <sdaftuar> ariard: that could be addressed by tx-relay-peer rotation, for what it's worth
15:28:39 <sdaftuar> but if the miners aren't running your policy you're in trouble!
15:28:44 <ariard> I agree assuming you rotate quick enough with regards to security timelocks
15:28:45 <sipa> ariard: aren't time sensitive things done on a scale of days/weeks/..., where this should be far less of a problem?
15:29:32 <ariard> sdafturar: I know, LN security is in fine dependent of power miners policy, i.e the ones likely to mine a block during the timelock
15:29:40 <ariard> and it's kinda a black box :(
15:29:58 <aj> sipa: i suppose on mainnet it could be amusing to have a well-known set of nodes that allow rbf-without-pinning (ie, will relay any tx as long as it has the rbf bit set, and pays more than the tx it's replacing, no worries how many it invalidates)
15:30:09 <sipa> so you can even do things like warning a user their time-sensitive tx isn't confirming
15:30:15 <ariard> sipa: here the tradeoff, we can always pickup higher timelocks, both for punishement and cltv delta but that come at the price in case of channel failure
15:30:32 <ariard> you increase the timevalue of locked funds for nothing
15:30:45 <aj> sipa: everybody else ignores it as spam, but it still gets to miners so avoids lightning txs getting pinned or whatever
15:31:06 <ariard> sipa: you might be under attack in the middle of the night, I lean to assume the same kind of automatic security model we have wrt to block validation
15:31:10 <sipa> aj: that seems problematic
15:32:02 <ariard> increasing timelocks on the long-term increase cost of LN routing fees, and thus utility of the overall system
15:32:18 <sipa> a node's rational policy should be to try to approximate the network's behavior
15:32:41 <ariard> because someone has to pay for the average expected failure, even if right now it's not priced at all by routing nodes
15:33:22 <ariard> sipa: I agree on this, like accept the lower bound to improve your feerate view, and also improve your local fee estimation
15:33:30 <ariard> thus lowering your fees, theoritically
15:33:55 <jnewbery> sorry, I've lost the thread a bit here. Are we specifically trying to solve a problem for taproot on signet here?
15:34:47 <ariard> jnewbery: thanks for the nudge, are p2p meeting for more theoritically discussions too :p ?
15:34:47 <troygiorshev> yeah for those of us looking to organize this, anyone want to summarize and/or give this a title?
15:35:12 <aj> jnewbery: allocating some service flags on signet seems to solve the problem okay on signet; trying to see if there's a better solution that usefully generalises to something that would be helpful on mainnet?
15:35:39 <sipa> i think we got a bit sidetracked... i don't think we're going to solve all problems with tx relay of time-sensitive transactions in a reliable way today..
15:35:49 <sdaftuar> i think the general question is whether it's worth worrying about differing transaction relay policies on our p2p network, and if so, to what extent
15:35:57 <sipa> aj: oh, just signet?
15:36:07 <jnewbery> it's fine to have theoretical discussions, i'm just a little lost as to what exactly we're discussing
15:36:13 <sipa> aj: can't you just create a new signet with taproot from the start?
15:36:25 <sipa> as in separate network
15:36:28 <aj> sipa: just signet, and only for the period while a soft-fork is in development, retired after it activates on mainnet (or becomes obsolete)
15:36:56 <aj> sipa: we're working on having this work in the default signet; having custom signets is definitely an additional/alternative option
15:37:16 <sipa> right, makes sense
15:37:33 <aj> https://github.com/bitcoin/bitcoin/issues/19787 has some discussion, maybe missing some context though
15:38:04 <jnewbery> aj: do you have any code or a more concrete proposal?
15:38:36 <aj> jnewbery: still working on a concrete proposal; code is at https://github.com/ajtowns/bitcoin/commits/signet-tr ; obviously subject to change
15:39:00 <ariard> sdaftuar: I'll open an issue resuming conversation, to scope security worries ones might have with tx-relay discrepancies
15:39:12 <jnewbery> thanks. Are you asking for review yet?
15:39:35 <aj> jnewbery: it allocates service flag 32 to indicate the current version of taproot; will bump to 33 when even-R taproot happens i think
15:39:52 <aj> jnewbery: not really; i'm trying to get it to run on a second node of my own first
15:40:05 <sipa> aj: so you will do a hardfork in signet?
15:40:53 <sdaftuar> amiti: i realized i never answered your question before, but i think that we don't even know exactly what our tx-relay goals are, let alone how to measure our progress against those goals, or how to improve things.
15:40:57 <aj> sipa: the idea is if you run "bitcoind -signet -experimental=taproot" then you'll get a hardfork event, and either have to drop the -experimental=taproot or upgrade to continue following the chain
15:41:28 <aj> sipa: the upgraded code will have taproot activate at a later mediantime so any prior transactions will just be random garbage that didn't need to be validated
15:42:12 <aj> sdaftuar: "that people don't complain on twitter and reddit about their txs not confirming" ? :)
15:42:30 * sipa suggests hardforking in paypal support
15:42:33 <sdaftuar> aj: haha if that's our only goal we can just get the moderators to filter those complaints out!
15:42:47 <aj> sdaftuar: censorship for the win
15:42:53 <ariard> aj: if we were binding to twitter-driven developpement why taproot isn't already activated :) ?
15:43:08 <sdaftuar> TDD = twitter driven development? TIL
15:43:29 <instagibbs> ariard, maybe it is *spooky music*
15:43:34 <jnewbery> Did everyone who wanted to have a chance to share what they're working at the start of the meeting?
15:43:47 <jnewbery> troygiorshev, amiti, fanquake, gzhao408, MarcoFalke, nehan: did you want to share anything?
15:44:00 <troygiorshev> i'll jump in briefly
15:44:02 <troygiorshev> since last time, I hosted a PR review club on #19509 per-peer message logging.  thanks to everyone who came!  some changes have been made and a few more will be in in the next few days.
15:44:06 <troygiorshev> i also encourage review on 19628 (myself included...)
15:44:07 <gribble> https://github.com/bitcoin/bitcoin/issues/19509 | Per-Peer Message Logging by troygiorshev · Pull Request #19509 · bitcoin/bitcoin · GitHub
15:44:10 <troygiorshev> if anyone is looking to dive into a relatively tedious net/net_processing unraveling, #19107 is still looking for review!
15:44:13 <gribble> https://github.com/bitcoin/bitcoin/issues/19107 | p2p: Move all header verification into the network layer, extend logging by troygiorshev · Pull Request #19107 · bitcoin/bitcoin · GitHub
15:44:18 <troygiorshev> that's all :)
15:44:24 <jnewbery> thanks troy!
15:44:42 <MarcoFalke> jnewbery: thx :). I was mostly working on 100% test coverage for p2p, but then got sidetracked/slowed down. I hope to pick that up soon
15:45:04 <amiti> marcofalke: 100%! I like this ambition.
15:45:09 <jnewbery> MarcoFalke: any PRs you want to shill, or still WIP?
15:45:23 <MarcoFalke> still WIP (or needing rebase)
15:45:33 <aj> (btw 50 days / 7 weeks 'til 0.21 feature freeze per 18947)
15:45:40 <nehan> jnewbery: thanks! i have a tiny PR to fix the lack of lock around vRecvGetData and orphan_work_set which I will open soon. Other than that, noting things here that need review.
15:45:53 <fanquake> I have nothing to share other than I’m trying to merge p2p PRs in some kind of sane order. Sorry if you have to rebase.
15:46:06 <jnewbery> MarcoFalke: let me know if there's any interaction/conflict with #19791
15:46:08 <sdaftuar> topic suggestion: 0.21 p2p goals?
15:46:08 <gribble> https://github.com/bitcoin/bitcoin/issues/19791 | [net processing] Move Misbehaving() to PeerManager by jnewbery · Pull Request #19791 · bitcoin/bitcoin · GitHub
15:46:31 <MarcoFalke> jnewbery: Shouldn't be any interaction
15:46:58 <jnewbery> sdaftuar: good idea. Let's see if there anyone else wants to share priorities/focus then move on to that
15:47:07 <ariard> wrt 0.21, tx-request overhaul? erlay?
15:47:11 <amiti> sdaftuar: agreed. I had spent a while trying to distill tx-relay goals, but its definitely tricky. have you seen sipa's description on #19184? it specifies a very clear list of goals
15:47:14 <gribble> https://github.com/bitcoin/bitcoin/issues/19184 | Overhaul transaction request logic by sipa · Pull Request #19184 · bitcoin/bitcoin · GitHub
15:47:58 <jnewbery> The thing I'd like to see prioritized in the short term are the backports: #19606 #19680 #19681
15:48:02 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
15:48:03 <gribble> https://github.com/bitcoin/bitcoin/issues/19680 | 0.20: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19680 · bitcoin/bitcoin · GitHub
15:48:04 <gribble> https://github.com/bitcoin/bitcoin/issues/19681 | 0.19: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19681 · bitcoin/bitcoin · GitHub
15:48:14 <sdaftuar> amiti: yes i think sipa's writeup is great for what we want a single node to do, i was referring to what we want overall network behavior to look like -- i think that is a big unknown
15:48:23 <amiti> ahhh
15:48:24 <jnewbery> and I also need to backport #19569 to v0.20 once 19606 is merged
15:48:27 <gribble> https://github.com/bitcoin/bitcoin/issues/19569 | Enable fetching of orphan parents from wtxid peers by sipa · Pull Request #19569 · bitcoin/bitcoin · GitHub
15:49:02 <jnewbery> #19680 and #19681 are very easy reviews, even if you didn't review the original PR
15:49:03 <gribble> https://github.com/bitcoin/bitcoin/issues/19680 | 0.20: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19680 · bitcoin/bitcoin · GitHub
15:49:04 <gribble> https://github.com/bitcoin/bitcoin/issues/19681 | 0.19: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19681 · bitcoin/bitcoin · GitHub
15:49:20 <jnewbery> and once 19681 is in, I think we can do a 0.19 release
15:49:29 <fanquake> jnewbery: is there any particular rush?
15:49:49 <fanquake> I think there’s still a few more things tagged for 0.19 before we cut a release
15:49:49 <jnewbery> fanquake: for 0.19 or the other ones?
15:49:53 <jnewbery> ah, ok
15:49:55 <fanquake> Either
15:49:58 <aj> maybe add the non-std input reject to high-pri? i thought there used to be a backports thing on that?
15:50:14 <jnewbery> aj: I'll add them
15:50:28 <jnewbery> although most of the people who'd review them are here right now :)
15:50:55 <jonatack> Is anyone working on overhauling peer misbehavior (e.g. measure resource usage by peers and penalise those peers consuming more of ours?) I think jnewbery is moving it into PeerManager, but besides that?
15:51:06 <jnewbery> #topic 0.21 p2p goals
15:51:18 <sdaftuar> so i think #19184 should be a goal for 0.21
15:51:20 <jnewbery> sdaftuar: want to start? We only have 9 minutes left
15:51:21 <gribble> https://github.com/bitcoin/bitcoin/issues/19184 | Overhaul transaction request logic by sipa · Pull Request #19184 · bitcoin/bitcoin · GitHub
15:51:39 <sdaftuar> other than that, i don't feel strongly -- and am curious what other things people would like
15:51:43 <troygiorshev> jonatack: i've been working on a pr measuring per peer resource usage
15:51:46 <sdaftuar> i'm guessing erlay is too ambitious
15:52:13 <jonatack> troygiorshev: great, ty
15:52:15 <jnewbery> +1 for 19184. I did a quick review, but I'm holding off doing a full review until sipa says it's ready
15:52:21 <sdaftuar> in particular, if there are some concrete features people want added, with 7 weeks to go we should try to round up review effort
15:52:35 <sipa> jnewbery: will do actually soon
15:52:36 <aj> progress on p2p testing a la amiti/marcofalke would be nice?
15:53:06 <jnewbery> 19184 may be ambitious for 0.21 if it's code freeze in 7 weeks?
15:53:16 <ariard> especially p2p testing of the eviction logic, if we aim to improve it in the future
15:53:21 <sipa> wow, 7 weeks already?
15:53:23 <aj> jnewbery: feature freeze, not code freeze
15:53:24 <MarcoFalke> aj: no progress from me for now
15:53:39 <sipa> well, should be doable i think
15:54:32 <sdaftuar> i haven't been following addrv2 very much
15:54:35 <jonatack> I think BIP155 addrv2 is a priority, according to vasild the next steps should be smaller and easier
15:54:35 <ajonas> this may have been asked elsewhere but is 19184 a requirement for taproot?
15:54:38 <sdaftuar> is that something that needs to be on a shorter timetable?
15:54:49 <jnewbery> ajonas: no
15:54:57 <amiti> I'd like to see #17428 make progress. reviewers have agreed on the benefits of at least some of the changes, but momentum slowed down on some of the specifics. if anyone wants to review and weigh in :)
15:55:00 <gribble> https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
15:55:24 <amiti> ariard: p2p testing of eviction logic would be awesome.
15:55:39 <jonatack> Tor v2 deprecation begins Sept 15
15:55:53 <sdaftuar> what's the addvr2 roadmap look like?  i don't know where we are at all.
15:56:01 <troygiorshev> #19031
15:56:03 <gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
15:56:36 <troygiorshev> we're, say, a bit over half way there?
15:56:51 <sdaftuar> are there remaining design considerations at this point, or is it all just implementation?
15:57:06 <sipa> sdaftuar: i think it's just implementation work
15:57:09 <jonatack> amiti: is anyone working of eviction testing atm?
15:57:18 <sdaftuar> thanks
15:57:26 <amiti> jonatack: not that I know of
15:58:11 <sdaftuar> so should we be aiming to get addrv2 into 0.21, or does that seem aggressive?
15:58:31 <jonatack> amiti: ty
15:58:58 <ariard> jonatack: I think we're pending on 19315 ? or make it easier with it ? need to review it to be sure
15:59:17 <jnewbery> seems doable. I haven't looked closely at the code but I think it's a smaller change than 19184 overhaul tx request logic
15:59:19 <sipa> sdaftuar: i think with #19628 we're over halfway there
15:59:22 <gribble> https://github.com/bitcoin/bitcoin/issues/19628 | net: change CNetAddr::ip to have flexible size by vasild · Pull Request #19628 · bitcoin/bitcoin · GitHub
15:59:34 <troygiorshev> sdaftuar: deprecated sept 15, and gone july 15 2021
15:59:41 <jonatack> addrv2 in 0.21 would be v worthwhile and agree, 19628 was probably the biggest chunk and it seems RFM
15:59:46 <sdaftuar> that sounds to me like we should prioritize it
15:59:50 <aj> troygiorshev: so desirable for 0.21 essential for 0.22?
15:59:51 <jnewbery> ok, 1 minute left. Anyone have anything they wanted to share before the end?
15:59:57 <ariard> amiti: wrt 17428, I concede gleb last point, too much advanced for now, though that would be great to have a clear map of connection types fingerprints
16:00:12 <sipa> #17428
16:00:16 <gribble> https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
16:00:18 <jnewbery> #endmeeting