21:01:33 <jnewbery> #startmeeting 
21:01:33 <core-meetingbot> Meeting started Tue Apr 20 21:01:33 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
21:01:33 <core-meetingbot> Available commands: action commands idea info link nick
21:01:36 <amiti> hi
21:01:39 <ajonas> hi
21:01:45 <jnewbery> hi folks
21:01:52 <ariard> hi
21:01:54 <gleb> Hi
21:01:56 <lightlike> hi
21:02:16 <jnewbery> As a reminder, everyone is free to share their p2p priorities here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
21:02:22 <promag> hi
21:02:39 <jnewbery> We also have three proposed topics for today's meeting:  https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#20-apr-2021
21:02:43 <gribble> https://github.com/bitcoin/bitcoin/issues/20 | JSON-RPC callback · Issue #20 · bitcoin/bitcoin · GitHub
21:02:45 <jnewbery> - Reduce addr blackholes (PR 21528) (Amiti)
21:02:49 <jnewbery> - Moving forward with asmap (gleb)
21:02:54 <jnewbery> - irc meetings on better L2s onchain support (ariard)
21:03:06 <jnewbery> Does anyone have any other proposed topics to add?
21:04:09 <jnewbery> oops, forgot
21:04:20 <jnewbery> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow 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
21:04:26 <jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
21:04:44 <jnewbery> alright, let's get into the first topic
21:04:57 <jnewbery> #topic Reduce addr blackholes (amiti)
21:04:58 <core-meetingbot> topic: Reduce addr blackholes (amiti)
21:05:02 <amiti> hi!
21:05:15 <amiti> I want to discuss #21528
21:05:17 <gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
21:05:37 <amiti> I've mentioned it in a few different places, but I'll start with an overview of goals & motivation
21:05:59 <amiti> The goal is to reduce addr blackholes- aka relaying self advertisements to peers who are unlikely to continue relaying it to the network. Doing so would be a standalone improvement for addr propagation, and also, in my opinion, help with the disabletx project.
21:06:23 <amiti> The PR serves as a proof of concept for how this can be implemented in Bitcoin Core, but is currently in a draft because I have been trying to build confidence that this wouldn’t harm other software on the network.
21:06:42 <amiti> I wrote to the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018784.html, and have not gotten any responses there
21:07:03 <amiti> I’ve also looked at the implementations of every other client I’ve heard of =P and been recording that here: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430
21:07:36 <amiti> looks like almost all other clients are definitely ok. the only one I was very confused about is bitcore, so I'm hoping someone will respond to the issue I opened
21:08:07 <amiti> so, my main question for today is- do people think its reasonable for me to move forward with these changes? aka bring the PR into a "ready for review" state ?
21:08:19 <ariard> does it document bitcoinj, it's still maintained afaik?
21:08:23 <gleb> It looks like the stuff I attempted to do around a year ago, and at the time I also concluded it won't hurt other software.
21:08:47 <amiti> bitcoinj is not on the list. will look & add
21:08:48 <jnewbery> Yes, concept ACK
21:08:54 <amiti> gleb: what did you attempt?
21:09:35 <amiti> oh, another link is to a previous bitcoin-dev meeting where we discussed: http://www.erisian.com.au/bitcoin-core-dev/log-2021-03-25.html#l-954
21:09:50 <gleb> amiti: stop forwarding addr to nodes when it's useless.
21:10:19 <amiti> gleb: what did you try? did you PR?
21:10:21 <ariard> imo that's okay to move "ready for review", if no one yells on the ml and main bitcoin libraries are behaving like core
21:10:58 <gleb> amiti: I had a PR #17194, a core meeting discussion and several ML posts.
21:11:01 <gribble> https://github.com/bitcoin/bitcoin/issues/17194 | p2p: Avoid forwarding ADDR messages to SPV nodes by naumenkogs · Pull Request #17194 · bitcoin/bitcoin · GitHub
21:11:15 <amiti> gleb: thanks! I didn't realize :)
21:11:18 <gleb> The PR is only covers a subset of stuff I was suggesting
21:12:14 <gleb> I'll take a look and probably close mine, in case your work auguments it.
21:12:24 <amiti> cool, I'll check it out
21:12:29 <sipa> amiti: where did you land on sending/nonsending to non-relay peers? i remember you had some comments for sdaftuar_
21:12:32 <sipa> *from
21:13:07 <jnewbery> gleb: your PR disables addr relay based on the service bits sent by the peer. amiti's enables addr relay based on previous addr/getaddr messages received from the peer
21:13:30 <amiti> I'm still exploring the approach of not sending to non-relay peers
21:14:40 <amiti> sdaftuar expressed concern that if there is other software that doesn't send addr/getaddr messages but are relying on addr messages to discover peers, this change could make them vulnerable to a poor addrman / eclipse attacks
21:14:40 <sipa> but that's what the PR does?
21:14:53 <amiti> sipa: what?
21:15:07 <lightlike> I think an important difference is that the new PR would prevent sending to peers for whom we are their block-relay-only peer.
21:15:32 <sipa> amiti: not announcing to (assumed to be) non-relaying peers
21:15:43 <amiti> sipa: correct
21:15:52 <amiti> sipa: sorry, I don't understand your question
21:16:08 <sipa> amiti: just wanted to make sure i was up to date on the approach
21:16:22 <jnewbery> sipa: does "non-relaying peers" = "inbound block-relay-only peers" ?
21:17:23 <amiti> some context for the group: an alternative approach would be to identify "potential blackholes" and then add redundancy if those are selected. eg if you intend to relay to 2 peers but select a "potential blackhole", additionally relay to another peer
21:17:36 <sipa> jnewbery: an alternative approach would be still sending addr messages to everyone, but treat some subset as non-relaying (and thus not counting towards the 1 or 2 relay slots)
21:17:46 <jnewbery> sipa: ah. Got it. Thanks
21:18:00 <sipa> jnewbery: which would less risky for the network, but in my opinion weakly exploitable
21:18:33 <jnewbery> 'for the network' seems vague
21:18:42 <sipa> if we're confident this won't break anything, the current approach has my preference
21:18:57 <amiti> that is also my preference :)
21:19:24 <jnewbery> it'd be less risky for peers that want to receive addrs but don't ask for addrs, or am I missing some transitive behaviour?
21:19:24 <sipa> jnewbery: software that doesn't getaddr or send addrs, but still relies on receiving addresses
21:19:55 <sipa> jnewbery: i don't expect such software to exist, but it's also hard to be certain
21:19:59 <jnewbery> sipa: yep, that's my understanding
21:20:11 <amiti> I don't see much indication we will break things. I'll check bitcoinj and hope to hear back from bitcore, but beyond that I don't think there's much else I can do from my end
21:20:19 <sipa> ok
21:20:36 <jnewbery> I think amiti is doing a good job at analyzing the possible risk here: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430
21:20:38 <ariard> at least ml + libraries inquiry let's build confidence, do we have other methods to improve such opinion?
21:21:02 <sipa> no, there is only so much we can do
21:21:35 <jnewbery> Great. Anything else on that, or shall we move to next topic?
21:21:45 <amiti> just to conclude -
21:21:56 <amiti> I'll continue moving forward. if anyone has outstanding concerns, please let me know :)
21:22:03 <amiti> thanks!
21:22:22 <jnewbery> amiti: great. Thank you!
21:22:28 <jnewbery> #topic Moving forward with asmap (gleb)
21:22:28 <core-meetingbot> topic: Moving forward with asmap (gleb)
21:22:34 <gleb> We (me and sipa) want to move asmap forward and the main question is how to enable it by default. So far one priority is to help the maintainer to keep track of the BGP topology state updates.
21:22:48 <gleb> Basically, the maintainer would have to re-generate the compressed BGP topology map (asmap) for distribution and make sure it’s valid.
21:23:12 <gleb> There’s also testing of the existing tools and code in the Core, feel free to help:
21:23:12 <gleb> https://blog.bitmex.com/call-to-action-testing-and-improving-asmap/
21:23:23 <gleb> Once these tools are ready and stable, we will be able to enable it by default I think. Let me know if you have any thoughts or suggestions for other TODO to make progress here, otherwise I’m done.
21:24:10 <ariard> Who is maintainer here ? bitcoin core or asmap tooling one?
21:24:28 <gleb> Bitcoin Core maintainers, every core release probably should get a new asmap file
21:24:47 <gleb> To maintain the best p2p robustness of the nodes.
21:24:50 <jeremyrubin> hi
21:25:25 <sipa> one critical component i think is tooling to produce human-readable diffs between asmap files
21:25:43 <sipa> because they can't be deterministically produced
21:26:10 <gleb> Yeah, everyone should be able to check the diff between the two easily.
21:27:07 <ariard> so it's about finishing asmap-rs as a functional bitcoin-asmap ?
21:27:27 <gleb> I think sipa still doesn't like rust, so we might end up using smething different...
21:28:03 <gleb> But basically yes, improving the tools.
21:28:28 <ariard> i think language choice is ultimately decided by who is maintaining the tool :p
21:29:09 <sipa> i certainly don't mind having good tooling in another language than one i'm familiar with, if it"s maintained
21:30:21 <gleb> I think I can commit to maintaining asmap-rs, but then, should we also translate sipa/asmap (compression part) into it?
21:30:31 <gleb> No need to answer now, I'll think about it after the meeting.
21:31:00 <ariard> gleb: nah you can link *.c/*.cpp in rust, we can talk about it in rust-bitcoin if you wanna
21:31:23 <gleb> alright, i'll check how nasty that is :)
21:32:33 <jnewbery> ariard: I don't think that's the problem. The question seems to be whether we should add some dependency on maintaining a rust tool to our release process.
21:32:51 <sipa> the only thing we neef reusable or usable from within Bitcoin Core is decoding/querying support, and we have that
21:33:36 <sipa> sure, it'd be nice if some tool shipped with core and possibly built from shared sources could do encoding too and other things, but i don't think that's a critical requirement
21:33:37 <ariard> jnewbery: yes as i'm planning to have rust dependency for altnet, if you think that's a real issue to have dependency in rust, let's have a discussion during main meeting?
21:33:49 <ariard> i think it was a subject a year ago
21:33:56 <sipa> those things just need to be available and usable
21:34:55 <jnewbery> ok, anything else on this topic, or move on?
21:35:04 <gleb> i think we can move on
21:35:09 <sipa> yeah
21:35:34 <jnewbery> #topic irc meetings on better L2s onchain support (ariard)
21:35:34 <core-meetingbot> topic: irc meetings on better L2s onchain support (ariard)
21:35:39 <ariard> hi!
21:36:18 <ariard> it has been a recurring topic among LN devs how to improve second-layer protocol layer by the base layer
21:36:28 <glozow> hi
21:36:36 <ariard> as current tx-relay and fee-bumping aren't really accurate
21:37:11 <ariard> we have the idea last year to do a share meeting between ln/core dev in 2021, but it doesn't seem it's going to be a thing even this year
21:37:44 <ariard> so instead, i'm working on setting up a bunch of  irc meeting to talk about stuff like dust, full-rbf, package relay, standardness, coordinated security disclosures
21:38:01 <ariard> started a new repo about problem space there : https://github.com/ariard/L2-zoology
21:38:19 <ariard> and will do an announcement on the ml latter this week about process
21:38:35 <ariard> feel free to contribute if you're interested by those topics :)
21:39:02 <gleb> ariard: i think to motivate people to come, you (or any coordinator) should be really clear on how this is going to be useful, what are the possible useful outcomes, and why this stuff is blocker for L2 protocols.
21:39:21 <sipa> i think it would be useful if this was more concrete
21:39:49 <ariard> gleb: yes how this is going to be useful is described in threats/ performance/ section of new repo, possible useful outcomes are changes like full-rbf or package-relay
21:39:59 <ariard> but sure we'll make this really clear in ml post
21:40:26 <glozow> i'd be interested in seeing some simulations of attacks
21:41:16 <sipa> people (ariard in particular) oftrn brings up issues of unreliability or certain lack of guarantees offered by the p2p protocol and its current implementations, but it's hard to discuss thst in general as there simply can't be any guarantees really, and other layers need to be aware of that... bit that doesn't mean we can't have useful discussions about specific features or so
21:41:19 <ariard> glozow: yes we can try them on signet or mainet, main issue is having a realistic mempool, with sudden spikes
21:42:09 <sipa> so it would be much more interesting to me at least to discuss specific features or proposals for the p2p protocol
21:42:25 <ariard> sipa: i know this non-reliability point would  be the starter point for such irc meetings
21:42:31 <sipa> rather than "fee bumping is insufficient"
21:42:59 <ariard> like there is quite a divide among L1 and L2 devs, and afaik matt or rusty I'm leaning toward more reliability expectations
21:43:17 <ariard> sipa: see rusty point here : https://github.com/bitcoin/bitcoin/issues/13283#issuecomment-398654468
21:43:57 <ariard> sipa: ultimately if we release something like package relay we have a question on the L2-side, is how much stability we can expect of such mechanism
21:44:10 <sipa> ariard: yeah the vbyte thing wasn't done as well as it could have been
21:44:27 <sipa> ariard: you can't expect transactions to be relayed, period
21:44:53 <sipa> they're likely to be, and we can discuss what will work in non-adverserial settings likely
21:45:05 <ariard> sipa: i agree, the best you can hope is an economic compatible tx-relay policy widely deployed on the network like bip125
21:45:51 <sipa> i'm afraid that economic compatibility is very hard without something like partial blocks
21:46:21 <sipa> because network bandwidth costs are ultimately in contradiction with always relaying the economically optimal final state
21:46:27 <ariard> sipa: by stability I didn't mean "every-full-node on the network must support it" more Core devs are not going to deprecate future or introduce api change break without some release process
21:46:38 <ariard> sipa: i don't know about partial blocks?
21:46:41 <sipa> oh, certainly
21:46:41 <glozow> er, what does economic compatible tx relay mean?
21:47:05 <sipa> glozow: say a tx is bumped by 1 satoshi in fee
21:47:12 <ariard> glozow: let's define better as incentive-compatible, apply this policy will increase your mempool feerate
21:48:09 <sipa> it won't get relayed by bitcoin core, because it's below the marginal feerate (the cost of relaying over the network is considered larger than what it's paying extra
21:48:20 <jnewbery> ariard: I don't think that's even it. incentive-compatible would mean that this policy increases the total fee of the top block's worth of transactions in your mempool
21:49:02 <sipa> glozow: but it is economically still better for miners to get that transaction; miner want it, but the network has no incentive to relay it
21:49:24 <sipa> that's a conflict, and the only general solution for it i know of is partial blocks
21:49:53 <ariard> jnewbery: i think accepting higher-feerate replacement transaction increase the odds to mine a higher fee block in the future?
21:50:10 <amiti> what is the goal from today's discussion?
21:50:18 <sipa> where miners broadcast partial solutions to PoW over the network (say at 1/10th the difficulty) to prove to the network "there is likely a significant portion of PoW working on this block"
21:50:39 <sipa> that would provide a natural incentive to switch mempools to the contents of such a blocm
21:50:40 <glozow> sipa: i see, thank you
21:51:20 <jnewbery> ariard: that's not incentive compatible for a miner. They only care about the contents of the next block.
21:51:21 <ariard> amiti: getting the feedbacks of folks here if they would like to participate to such meetings, once we have a clear scope :)
21:52:09 <glozow> oh cool, similar to like mining pool partial solutions for reward shares
21:52:29 <jnewbery> ariard: when are you planning to do this irc meeting?
21:52:33 <glozow> like broadcasting "this is the block i'm working on" before finding the solution
21:52:40 <sipa> glozow: indeed
21:53:08 <ariard> jnewbery: depends of your miner model? even if they loss the race to mine next block, they are still willingly to optimize fee of following blocks
21:53:14 <jnewbery> any final topics before we wrap up?
21:53:25 <ariard> jnewbery: end of may/june
21:53:35 <jnewbery> ariard: thanks!
21:53:47 <ariard> i'm done, thanks for your feedbacks :)
21:53:48 <sipa> glozow: and partial PoW means a natural rate limit for such partial blovks
21:54:00 <glozow> ariard: I'm interested in such a meeting if you're able to coordinate a time
21:54:01 <glozow> apart from that, I'll keep an eye on the docs in your repo, and am interested in turning some of them into functional tests or simulations for a more concrete measure of the attacks
21:54:27 <ariard> glozow: coool let me get back to you to do simulation of attacks!
21:54:51 <amiti> I'd be happy to participate if there was a clear scope, agenda & goals. I agree with sipa that its hard to make much progress in a purely abstract conversation.
21:55:07 <amiti> (around p2p guarantees)
21:55:21 <darosior> ariard: (re-mentioning here) happy to participate too
21:55:24 <ariard> amiti: that's the reason of braindumping in a repo to avoid abstract conversation (and working on attacks simulation)
21:55:35 <amiti> cool!
21:56:06 <jnewbery> seems like that's all. Thanks everyone!
21:56:09 <jnewbery> #endmeeting