21:00:11 <jnewbery> #startmeeting 
21:00:11 <core-meetingbot> Meeting started Tue Mar  9 21:00:11 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
21:00:11 <core-meetingbot> Available commands: action commands idea info link nick
21:00:17 <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:00:23 <jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
21:00:27 <amiti> hi
21:00:28 <hebasto> hi
21:00:34 <gleb> hi
21:00:39 <ariard> hi
21:00:48 <emzy> hi
21:00:50 <aj> hi
21:00:52 <ajonas> hello
21:01:03 <jnewbery> topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
21:01:24 <jnewbery> contributors' current priorities are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
21:01:47 <jnewbery> There's one proposed topic this week: Erlay (gleb). Before we do that, does anyone have any other proposed topics or short updates?
21:02:06 <aj> would be interested in an update on disabletx and the thread on -dev about it
21:02:12 <ajonas> I have a something i put together addrman and eclipse attacks (not quite a full topic)
21:02:19 <fjahr> hi
21:02:31 <ajonas> it should only take a couple of minutes
21:02:45 <jnewbery> aj: yep, we can do that
21:03:01 <jnewbery> ajonas: ok, if it's quick let's do that first
21:03:09 <jnewbery> #topic addrman and eclipse attacks (ajonas)
21:03:10 <core-meetingbot> topic: addrman and eclipse attacks (ajonas)
21:03:30 <ajonas> This is a doc I put on the wiki: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Addrman-and-eclipse-attacks
21:03:42 <ajonas> feedback would be appreciated
21:04:05 <ajonas> Thank you to those that helped track down the details and reviewed
21:04:16 <ajonas> fin
21:04:35 <jnewbery> thanks ajonas!
21:04:46 <jnewbery> any questions or should we move on to the next topic?
21:04:49 <ariard> ajonas: consider those papers https://www.comp.nus.edu.sg/~kangms/papers/erebus-attack.pdf and https://btc-hijack.ethz.ch/files/btc_hijack.pdf on infrastructure-level eclipse attacks against bitcoin nodes
21:05:25 <gleb> pretty sure the former one is included
21:06:18 <ariard> right it mentipns asmap which is only one of the mitigation proposed in erebeus paper iirc
21:06:53 <ariard> (but better to do feedback after meeting, let's mov on)
21:07:00 <jnewbery> next topic?
21:07:08 <jnewbery> #topic erlay (gleb)
21:07:08 <core-meetingbot> topic: erlay (gleb)
21:07:19 <gleb> Hi! Just a little update here. I was working on Erlay refactor in a separate branch, currently addressing great comments from jnewbery and ariard. Gonna finish that in a day or two.
21:08:01 <gleb> jnewbery: perhaps we'll invite everyone to full review again, after you give a quick skim of the high-level encapsulation approach etc in couple days?
21:08:23 <gleb> or i should just do it once im done, if you think it's good enough?
21:09:08 <gleb> just trying to make review more focused and optimize efforts
21:09:20 <phantomcircuit> HELLO
21:09:55 <jnewbery> gleb: I've left my comments. I don't think you need to wait for another round from me before opening a PR for the new branch.
21:10:09 <phantomcircuit> jnewbery, i'd like to talk about #21106 today as well
21:10:12 <gribble> https://github.com/bitcoin/bitcoin/issues/21106 | persist IBD latch across restarts by pstratem · Pull Request #21106 · bitcoin/bitcoin · GitHub
21:10:24 <gleb> jnewbery: alright, thank you. that's the plan then
21:10:33 <gleb> im done :)
21:11:16 <jnewbery> phantomcircuit: sounds good. Thanks
21:11:26 <jnewbery> any questions about erlay before the next topic?
21:11:43 <sipa_> hi
21:12:07 <jnewbery> #topic update on disabletx (aj)
21:12:07 <core-meetingbot> topic: update on disabletx (aj)
21:13:18 <aj> jnewbery's post makes sense to me -- that we can use frelay and avoid needing disabletx; but i don't understand ariard's response; and see suhas has updated the pr some more
21:14:25 <amiti> +1
21:15:25 <jnewbery> aj: did you read the log from the general bitcoin core irc meeting last week? There was quite a lot of discussion about using a -blocksonly node and occasionally sending txs from it
21:16:25 <aj> jnewbery: i did, but as i understand it we can cope with that via fRelay fine
21:17:24 <jnewbery> I hadn't thought about it any more since then, but I wasn't sure if we could cope with that via fRelay
21:18:16 <ariard> aj: my point was bip37 original scope was unclear if it concerns only inv(tx) or any tx-related message, bip338 has the merit to clarify
21:18:46 <jnewbery> the scenario is that you have a border node, and then a core node that only connects to that border node, and is -blocksonly. You want to be able to send txs from the core node to the border node. If we disallowed tx relay based on fRelay=false, then that wouldn't work(?)
21:18:52 <aj> jnewbery: hmm, i think what i specced out in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018526.html is self-consistent and works with -blocksonly sensibly, can't guarantee it's properly backwards compatible (didn't look hard enough)
21:19:32 <aj> jnewbery: it differentiates tx's based on direction -- ie if i say fRelay=false, you won't send txs to me, but i might send the to you
21:20:13 <jnewbery> txRelay isn't required for receiving txs?
21:20:29 <jnewbery> if that's the case, then I think I agree with you, but need to think about it some more
21:20:49 <aj> txrelay isn't required for receiving i think, just trequest.cpp
21:20:54 <aj> trequest.cpp
21:20:55 <aj> gah
21:20:59 <aj> txrequest.cpp
21:21:20 <jnewbery> aj: yes, I think you're right
21:21:26 <amiti> some small changes are needed to support, but yeah, we don't need the whole txrelay struct to receive
21:23:21 <aj> ariard: i think bip 37 without bip 111 (the service bit) is pretty dead? bip 60 seems to match what i described above
21:24:27 <jnewbery> aj: I agree
21:24:29 <aj> ariard: if you advertise the bloom service bit, then i think you just treat that as no possibility of being lightweight, and everything works fine; and obv if you don't advertise the service bit, you already kill the connection if they try doing bloom stuff to you
21:25:20 <jnewbery> (I've pinged sdaftuar, since he's probably interested in this)
21:25:32 <sdaftuar> hi, sorry i'm late to the discussion. i don't understand why we'd go to these contortions to avoid a new p2p message, but if someone is interested in implementing this a different way, please feel free
21:26:14 <aj> sdaftuar: i think it should not end up that twisted fwiw
21:26:15 <ariard> aj: bip 60 "Whether the remote peer should announce relayed transactions or not" is a bip-60 compliant client allows to send TX messages after receiving `fRelay=false`
21:26:58 <aj> ariard: i don't follow what you said?
21:27:37 <jeremyrubin> sdaftuar: don't we only have 8e28 possible p2p messages?
21:28:13 <sipa> i think fewer p2p messages with meanings that differ slightly across versions is slightly worse than separate ones with clear well defined meaning :)
21:28:58 <aj> ariard: I run a -blocksonly node. You run a bip60 compliant node. I tell you fRelay=false. You don't send me any txes. You told me fRelay=true. Therefore I can send you a tx, without violating bip60.
21:30:29 <ariard> aj: that's my point the "You don't send me any txes" isn't clearly documented in the bip, a naive implementation of bip 60 could try to send raw, unannounced TX messages
21:31:52 <ariard> and don't understand why the connection is severed
21:32:21 <sipa> if you're going by reading the spec by the letter... what does bip60"s fRelay flag even mean for a client that chooses not.to implement bip37?
21:32:48 <amiti> I'd like explicit p2p messages with clear meanings, but what I don't like about the current disabletx proposal is the implicit disabling of addrs. I understand the hesitation to want to have a better understanding of addr relay before implementing a new protocol message, but I think that having disabletx implicitly disable addrs would make it harder for us to have clear, explicit messages about relay in the
21:32:48 <amiti> long-term. so that makes me more inclined to use what we have, since it suffices
21:32:57 <aj> ariard: it's always the sender's choice to not send a tx?
21:33:35 <ariard> aj: right but imo current bip60 semantic isn't clear with what the sender is allowed to do
21:34:18 <sipa> aj: i think ariard is trying to point out that bip37/bip60 only talk about *announcing* transactions, not sending (possibly unannounced) transactions
21:35:58 <sipa> amiti: i think that's fair... i also don't really know what the issue would be with a sendaddrtypes message with a bitvector of bip155 network types for example (apart from not wanting to deal with that too right now)
21:35:59 <aj> sipa: ie, if I say fRelay=false, ariard shouldn't send me INVs but perhaps should reply to a GETDATA with a TX?
21:36:17 <ariard> yes that's it, and sending unannounced transactions is tolerated behavior for now
21:36:44 <sipa> aj: maybe, or maybe he could still send you an unannounced transaction
21:37:52 <aj> ariard: hmm. i wouldnt tolerate a TX message from you if i'd connected to you as a block-relay-only peer
21:39:25 <jnewbery> ok, next topic?
21:39:37 <aj> anyway, should we let phantomcircuit have the floor?
21:39:42 <jnewbery> thanks aj
21:40:00 <jnewbery> #topic IBD latch across restarts (phantomcircuit)
21:40:00 <core-meetingbot> topic: IBD latch across restarts (phantomcircuit)
21:40:07 <ariard> aj: how I know I'm a block-relay-only peer ? e.g what the exact scope of "block-relay-only"?
21:40:14 <ariard> but yeah let's move on
21:40:21 <phantomcircuit> eh hem
21:41:34 <phantomcircuit> after discussing this with a number of people sipa and sdaftuar especially i think the better approach to a network event that latches all of the listening peers into ibd is simply to make the headers sync peer selection algorithm looser at intervals since we made progress on getting out of ibd
21:41:54 <phantomcircuit> that more directly addresses the issue
21:42:18 <sipa> phantomcircuit: did you see sdaftuar last's response where he suspects the issue is block fetching, not header syncinf?
21:42:22 <phantomcircuit> (can also serve headers when we're past the chains minimum work regardless of ibd)
21:43:32 <phantomcircuit> sipa, yes, we discussed it here, he missed that compact blocks received will not trigger a getheaders when we're in ibd
21:43:51 <sipa> ah
21:44:04 <sipa> so what precisely do you propose to address this?
21:45:02 <phantomcircuit> if we haven't made progress on headers sync in at least INTERVAL time simply request headers from all peers
21:45:47 <phantomcircuit> im sure there's more nuisanced solutions that could be employed but that's the most direct to prevent the issue
21:46:25 <gleb> is there a summary of the issue and this discussion anywhere? I find it difficult to follow without prior context
21:46:43 <sipa> #21106 
21:46:45 <gribble> https://github.com/bitcoin/bitcoin/issues/21106 | persist IBD latch across restarts by pstratem · Pull Request #21106 · bitcoin/bitcoin · GitHub
21:46:51 <gleb> thanks
21:47:30 <jnewbery> phantomcircuit: The scenario that you're trying to address (all or most of the listening nodes are restarted) seems like it'd always need some kind of manual intervention.
21:47:34 <aj> this was the recent dogecoin network failure more or less?
21:47:55 <emzy> I think so.
21:48:42 <phantomcircuit> jnewbery, sure, lets say there's a crash bug, which has existed in the past
21:49:08 <sipa> aj: yes
21:49:25 <phantomcircuit> i'll note that what i describe in the pr has happened on an altcoin derived from the bitcoin codebase and is relatively recently backported so it's not ancient nonsense
21:50:00 <sipa> 0.14 iirc
21:50:33 <aj> phantomcircuit: (nuanced, not nuisanced :)
21:50:47 <aj> header polling sure sounds better than perma-latching !IBD to me?
21:51:30 <sipa> phantomcircuit: given that the dont-ask-headers-from-everyone is purely a bandwidth-preservation heuristic, i think it makes perfect sense to disable/weaken it in cases where we're worrying about being unable to sync
21:52:11 <jnewbery> it's really difficult to follow the PR to be honest. I
21:52:19 <jnewbery> I'm not surprised that people are confused
21:52:35 <sipa> ignore the code in the PR, it's just the discussion there that matters
21:52:39 <jnewbery> there seem to have been several different approaches, and then comments left and later deleted
21:52:43 <sipa> the code will be very different once it's hammered out
21:53:55 <sipa> phantomcircuit, sdaftuar: would it be possible to just post a summary/update of your understanding of what should be addressed?
21:54:49 <jnewbery> that seems like a sensible next step
21:55:03 <sipa> because it seems there has been some progress on IRC that's not mentioned there
21:55:56 <phantomcircuit> aj, English is hard
21:56:21 <aj> phantomcircuit: nuance is often a nuisance, to be fair
21:56:22 <sipa> but in any case, if there's reasonable evidence that all we need to do is making headers syncing less restrictive, i think weakening just that in case we haven't found new headers in a while seems like a reasonable approach
21:56:42 <phantomcircuit> sipa, it's a little confusing, since there's a bunch of things that are potentially separately contributing to the issue
21:56:44 <sipa> aj: that's a pretty unnuanced statement
21:57:39 <jnewbery> ok, anyone have any final updates before we close the meeting?
21:57:57 <phantomcircuit> sipa, i think relaxing the headers sync peer selection combined with serving headers if we're past minwork would get us a long way, but we ban peers for sending headers which are below out minwork and the minwork goes up overtime, so old peers that are restarted could get banned
21:59:01 <sipa> phantomcircuit: but the banning is only for headers pre-last-checkpoint, which is ancient
21:59:19 <sipa> and if clients are introduce a new checkpoint that'd need huge scrutiny anyway
22:00:24 <sipa> so maybe that's not crazy to assume that any minpeerwork is going to be past any-reasonable-client's checkpoints
22:00:43 <jnewbery> #endmeeting