15:00:13 #startmeeting 15:00:13 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:21 hi 15:00:23 hi 15:00:24 hi 15:00:24 hi 15:00:26 hi 15:00:28 hi 15:00:29 hi 15:00:52 hi 15:01:05 #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 hi 15:01:11 amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2 15:01:26 hi folks. Welcome to p2p meeting 2! 15:01:36 hi 15:01:40 #topic priority/focus 15:01:54 Does anyone have any updates that they want to share since last week? 15:02:05 y 15:02:08 feel free to jump in 15:02:24 s/last week/last meeting/ 15:02:27 My prios were BIP155, BIP324, and BIP325 implementation PRs, and they seem to be moving forward. 15:02:30 just after jon :) 15:02:35 hi 15:02:37 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 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 it seems to be close 15:02:58 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 https://github.com/bitcoin/bitcoin/issues/18267 | BIP-325: Signet [consensus] by kallewoof · Pull Request #18267 · bitcoin/bitcoin · GitHub 15:03:09 (sorry if that isn't p2p) 15:03:12 hi 15:03:14 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 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 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 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 I encourage people to review BIP 324 and the PR 18242. 15:04:20 hi 15:04:23 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 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 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 finnaly 15:04:52 jonatack: yeah, i need to respond to llfourn's comments 15:04:53 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 Thanks to fjahr, jnewbery, and vasild who have reviewed it so far! Review welcome. 15:05:04 that's it for me :p 15:05:07 hi 15:05:46 I've been trying to keep track of the #18044 clean-ups. 15:05:51 https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub 15:05:56 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 and then there are the backports 15:07:02 my prios are #17785 and #17428 15:07:05 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 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 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 ajonas: i think my followup is dome already (#19569) 15:07:26 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 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 sipa: I'll take a look. Thanks. 15:07:56 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 and the DoS concern are more theoritical, given you have easier alternatives 15:08:11 ariard: no changes, just commentary, iirc - but i need to go through it in more detail 15:08:58 i've been thinking about small topology improvements, specifically picking up the main idea of #16859 15:08:59 https://github.com/bitcoin/bitcoin/issues/16859 | Syncing headers with feeler-peers · Issue #16859 · bitcoin/bitcoin · GitHub 15:09:16 well, that's only sort of a topology improvement, depending on implementation, actually 15:09:39 the main idea is to sync headers with more peers, and potentially replace peers with new ones as well 15:09:46 hopefully PR to come soon-ish 15:10:25 are we eventually just going to split up all functionality, and have header-peers, block-peers, tx-peers, addr-peers? :) 15:10:46 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 sipa: separating addr-peers sounds weird, but all the rest of it... 15:11:01 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 like upgrading them to block-peers and evvicting one in consequence if max outboounds reach 15:11:13 and the other where i treat it as an extra block-relay-only peer that can evict another block-relay peer 15:11:26 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 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 though likely more compelx of implementation 15:13:19 aj: just so that txn would propagate well? 15:13:30 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 maybe not store headers, just mark them as known-as-useful-peers 15:13:57 sipa: s/well/at all/, yeah 15:14:11 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 which is mostly a per-peer memory savings 15:14:51 and then hopefully we can increase the number of inbounds (specifically carve out extra inbound slots for block-relay peers) 15:15:02 and then increase the number of block-relay outbound connections we make too 15:15:28 so i'm planning to pick that up as well in the near term 15:15:46 > now that i have clarity on how to propose new feature negotiation 15:15:50 ^ it wasn't clear to me what the outcome of the mailing list discussion was. What are you proposing? 15:15:52 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 related #19723 15:15:59 https://github.com/bitcoin/bitcoin/issues/19723 | Ignore unknown messages before VERACK by sdaftuar · Pull Request #19723 · bitcoin/bitcoin · GitHub 15:16:00 jnewbery: just accompany new features with a protocol version bump 15:16:10 but otherwise copy what has been done before 15:16:33 seems to me that path is basically unobjectionable 15:17:02 it works okayish 15:17:10 forcing protocol changes to be serial seems not as good as being able to opt in to different features 15:17:27 i think we can deal with that when we actually get protocol version number conflicts? 15:17:31 seems like it doesn't happen in practce 15:17:34 sipa: yeah, not much fun if your transactions don't propogate though 15:17:37 sdaftuar: fair 15:18:00 and i don't think we can force other implementations to adopt anything generic (like i proposed) 15:18:06 so i think it's easy for now to accommodate those preferences 15:18:21 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 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 hm, we've not historically used service bits for tx-relay properties right? 15:19:24 sipa: yep. blocks-only happens after tx-carrying ones atm; which is maybe backwards? 15:19:41 sdaftuar: indeed 15:19:51 i'm a bit hesitant about that... 15:20:14 we don't have a good framework for thinking about transaction propagation imo 15:20:44 right, and that's something we need for higher layer :) 15:21:14 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 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 aj: also, this isn'ta actually specific to softforks, but to policy cjangs 15:21:27 sipa: exactly 15:21:38 sipa: yep 15:21:43 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 so far we haven't assumed we can reasom about peer's tx policies 15:21:52 i don';t know 15:21:54 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 arguably, we do already, in the form of feefilter 15:22:43 that is effectively tellings peer part of our relay policy 15:23:22 with automatic tx rebroadcast there may be slightly less need for this 15:23:26 there are so many things that can go wrong with respect to transactions you have not propagating well 15:23:28 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 aj: i feel it's a can of worms, trying to do this well 15:24:01 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 automatic tx rebroadcast + tx-relay-peer rotation might be the most robust thing we can do? 15:24:09 at least a subset 15:25:04 plus the philosophical issue that it means assumptions on being to rely on (claimed/standardized) policy 15:25:07 sipa: sure. i only really care about doing it adequately at this point :) 15:25:24 so, eh 15:25:33 why hasn't this historically been needed? 15:25:39 :) 15:25:46 sipa: I agree that's a philosophical issue but that was implicetely part of any payment channel design with timelocks 15:25:54 sipa: because everyone upgrades before the policy change activates? 15:26:06 aj: right 15:26:07 sipa: then no one transacts with the changed policy for a while anyway 15:26:10 none of your peers accepting a softfork policy may tell you something too :) 15:26:12 wait for some LN implementation being broken for forgetting some policy check 15:26:25 ariard: i feel that's a mistake, tbh 15:26:57 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 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 time-sensitive tx A 15:28:22 ariard: that could be addressed by tx-relay-peer rotation, for what it's worth 15:28:39 but if the miners aren't running your policy you're in trouble! 15:28:44 I agree assuming you rotate quick enough with regards to security timelocks 15:28:45 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 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 and it's kinda a black box :( 15:29:58 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 so you can even do things like warning a user their time-sensitive tx isn't confirming 15:30:15 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 you increase the timevalue of locked funds for nothing 15:30:45 sipa: everybody else ignores it as spam, but it still gets to miners so avoids lightning txs getting pinned or whatever 15:31:06 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 aj: that seems problematic 15:32:02 increasing timelocks on the long-term increase cost of LN routing fees, and thus utility of the overall system 15:32:18 a node's rational policy should be to try to approximate the network's behavior 15:32:41 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 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 thus lowering your fees, theoritically 15:33:55 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 jnewbery: thanks for the nudge, are p2p meeting for more theoritically discussions too :p ? 15:34:47 yeah for those of us looking to organize this, anyone want to summarize and/or give this a title? 15:35:12 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 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 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 aj: oh, just signet? 15:36:07 it's fine to have theoretical discussions, i'm just a little lost as to what exactly we're discussing 15:36:13 aj: can't you just create a new signet with taproot from the start? 15:36:25 as in separate network 15:36:28 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 sipa: we're working on having this work in the default signet; having custom signets is definitely an additional/alternative option 15:37:16 right, makes sense 15:37:33 https://github.com/bitcoin/bitcoin/issues/19787 has some discussion, maybe missing some context though 15:38:04 aj: do you have any code or a more concrete proposal? 15:38:36 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 sdaftuar: I'll open an issue resuming conversation, to scope security worries ones might have with tx-relay discrepancies 15:39:12 thanks. Are you asking for review yet? 15:39:35 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 jnewbery: not really; i'm trying to get it to run on a second node of my own first 15:40:05 aj: so you will do a hardfork in signet? 15:40:53 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 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 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 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 aj: haha if that's our only goal we can just get the moderators to filter those complaints out! 15:42:47 sdaftuar: censorship for the win 15:42:53 aj: if we were binding to twitter-driven developpement why taproot isn't already activated :) ? 15:43:08 TDD = twitter driven development? TIL 15:43:29 ariard, maybe it is *spooky music* 15:43:34 Did everyone who wanted to have a chance to share what they're working at the start of the meeting? 15:43:47 troygiorshev, amiti, fanquake, gzhao408, MarcoFalke, nehan: did you want to share anything? 15:44:00 i'll jump in briefly 15:44:02 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 i also encourage review on 19628 (myself included...) 15:44:07 https://github.com/bitcoin/bitcoin/issues/19509 | Per-Peer Message Logging by troygiorshev · Pull Request #19509 · bitcoin/bitcoin · GitHub 15:44:10 if anyone is looking to dive into a relatively tedious net/net_processing unraveling, #19107 is still looking for review! 15:44:13 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 that's all :) 15:44:24 thanks troy! 15:44:42 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 marcofalke: 100%! I like this ambition. 15:45:09 MarcoFalke: any PRs you want to shill, or still WIP? 15:45:23 still WIP (or needing rebase) 15:45:33 (btw 50 days / 7 weeks 'til 0.21 feature freeze per 18947) 15:45:40 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 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 MarcoFalke: let me know if there's any interaction/conflict with #19791 15:46:08 topic suggestion: 0.21 p2p goals? 15:46:08 https://github.com/bitcoin/bitcoin/issues/19791 | [net processing] Move Misbehaving() to PeerManager by jnewbery · Pull Request #19791 · bitcoin/bitcoin · GitHub 15:46:31 jnewbery: Shouldn't be any interaction 15:46:58 sdaftuar: good idea. Let's see if there anyone else wants to share priorities/focus then move on to that 15:47:07 wrt 0.21, tx-request overhaul? erlay? 15:47:11 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 https://github.com/bitcoin/bitcoin/issues/19184 | Overhaul transaction request logic by sipa · Pull Request #19184 · bitcoin/bitcoin · GitHub 15:47:58 The thing I'd like to see prioritized in the short term are the backports: #19606 #19680 #19681 15:48:02 https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub 15:48:03 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 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 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 ahhh 15:48:24 and I also need to backport #19569 to v0.20 once 19606 is merged 15:48:27 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 #19680 and #19681 are very easy reviews, even if you didn't review the original PR 15:49:03 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 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 and once 19681 is in, I think we can do a 0.19 release 15:49:29 jnewbery: is there any particular rush? 15:49:49 I think there’s still a few more things tagged for 0.19 before we cut a release 15:49:49 fanquake: for 0.19 or the other ones? 15:49:53 ah, ok 15:49:55 Either 15:49:58 maybe add the non-std input reject to high-pri? i thought there used to be a backports thing on that? 15:50:14 aj: I'll add them 15:50:28 although most of the people who'd review them are here right now :) 15:50:55 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 #topic 0.21 p2p goals 15:51:18 so i think #19184 should be a goal for 0.21 15:51:20 sdaftuar: want to start? We only have 9 minutes left 15:51:21 https://github.com/bitcoin/bitcoin/issues/19184 | Overhaul transaction request logic by sipa · Pull Request #19184 · bitcoin/bitcoin · GitHub 15:51:39 other than that, i don't feel strongly -- and am curious what other things people would like 15:51:43 jonatack: i've been working on a pr measuring per peer resource usage 15:51:46 i'm guessing erlay is too ambitious 15:52:13 troygiorshev: great, ty 15:52:15 +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 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 jnewbery: will do actually soon 15:52:36 progress on p2p testing a la amiti/marcofalke would be nice? 15:53:06 19184 may be ambitious for 0.21 if it's code freeze in 7 weeks? 15:53:16 especially p2p testing of the eviction logic, if we aim to improve it in the future 15:53:21 wow, 7 weeks already? 15:53:23 jnewbery: feature freeze, not code freeze 15:53:24 aj: no progress from me for now 15:53:39 well, should be doable i think 15:54:32 i haven't been following addrv2 very much 15:54:35 I think BIP155 addrv2 is a priority, according to vasild the next steps should be smaller and easier 15:54:35 this may have been asked elsewhere but is 19184 a requirement for taproot? 15:54:38 is that something that needs to be on a shorter timetable? 15:54:49 ajonas: no 15:54:57 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 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 ariard: p2p testing of eviction logic would be awesome. 15:55:39 Tor v2 deprecation begins Sept 15 15:55:53 what's the addvr2 roadmap look like? i don't know where we are at all. 15:56:01 #19031 15:56:03 https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub 15:56:36 we're, say, a bit over half way there? 15:56:51 are there remaining design considerations at this point, or is it all just implementation? 15:57:06 sdaftuar: i think it's just implementation work 15:57:09 amiti: is anyone working of eviction testing atm? 15:57:18 thanks 15:57:26 jonatack: not that I know of 15:58:11 so should we be aiming to get addrv2 into 0.21, or does that seem aggressive? 15:58:31 amiti: ty 15:58:58 jonatack: I think we're pending on 19315 ? or make it easier with it ? need to review it to be sure 15:59:17 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 sdaftuar: i think with #19628 we're over halfway there 15:59:22 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 sdaftuar: deprecated sept 15, and gone july 15 2021 15:59:41 addrv2 in 0.21 would be v worthwhile and agree, 19628 was probably the biggest chunk and it seems RFM 15:59:46 that sounds to me like we should prioritize it 15:59:50 troygiorshev: so desirable for 0.21 essential for 0.22? 15:59:51 ok, 1 minute left. Anyone have anything they wanted to share before the end? 15:59:57 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 #17428 16:00:16 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 #endmeeting