21:00:18 <jnewbery> #startmeeting 
21:00:18 <core-meetingbot> Meeting started Tue Feb 23 21:00:18 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
21:00:18 <core-meetingbot> Available commands: action commands idea info link nick
21:00:22 <amiti> hi!
21:00:26 <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:32 <jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
21:00:33 <glozow> hi
21:00:35 <gleb> hi!
21:00:46 <sipa> hi
21:00:46 <ariard> hi
21:01:03 <hebasto> hi
21:01:25 <aj> hola
21:01:33 <lightlike> hi
21:01:36 <jnewbery> hi folks. Proposed meeting topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#23-feb-2021. Current priorities are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
21:01:39 <gribble> https://github.com/bitcoin/bitcoin/issues/23 | CORS support by gavinandresen · Pull Request #23 · bitcoin/bitcoin · GitHub
21:01:55 <jnewbery> buenos dias aj!
21:02:14 <jnewbery> #topic erlay update (gleb)
21:02:14 <core-meetingbot> topic: erlay update (gleb)
21:02:35 <gleb> I’m grateful to all folks pushed me to refactor #18261 in a similar way to txrequest.cpp.
21:02:38 <gribble> https://github.com/bitcoin/bitcoin/issues/18261 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #18261 · bitcoin/bitcoin · GitHub
21:02:42 <gleb> I’m almost done with that, just need to split cpp/header, split into commits, and add a bit more comments. Gonna be ready in the next couple days.
21:02:55 <gleb> jnewbery jonatack amiti I recall you mentioned you’d prefer a more modular appoach. Would any of you be able to take a look during this week, before I update the main PR?
21:02:55 <aj> jnewbery: good nachos to you too!
21:03:00 <gleb> I would really appreciate initial feedback on the new modularity, and I think this would also help to save review time of those folks focusing on other aspects of the PR.
21:03:08 <gleb> It’s just that if this new approach is also not really good (for now I personally think it is good), I’d prefer us realizing it earlier, and re-shaping it again.
21:03:25 <prayank> jnewbery: TIL aj is working on Dandelion
21:03:51 <jnewbery> gleb: sure, I'm happy to take a look at it
21:04:12 <gleb> jnewbery. Great, thanks. If anyone else is willing to join john, please let me know :)
21:04:26 <gleb> Otherwise, that's it.
21:04:38 <jnewbery> where is it? how do you want me to leave review?
21:05:02 <amiti> gleb: I'm also down
21:05:02 <gleb> It's under naumenkogs/bitcoin/tree/erlay_refactored, but it's currently not ready yet, as I said.
21:05:26 <jnewbery> I also still think PRing minisketch separately would help move things forward
21:05:29 <sipa> perhaps leave a comment on the PR when you're done with the refactoring and want comments?
21:05:48 <ariard> or leave a message on irc here
21:05:59 <gleb> jnewbery: yeah, since c++ headers is merged, we can probably PR minisketch
21:06:37 <gleb> sipa: I'm wondering if you'd be a better candidate for merging minisketch? Just realistically, discussing the code and such
21:06:48 <gleb> Or you'd rather me do it?
21:07:01 <gleb> Not merging but creating PR I mean.
21:07:09 <sipa> i'll open a PR to fix the issue that the current minisketch tests run forever (which is unexpected and confuses people)
21:07:16 <sipa> i think after that we could
21:07:25 <sipa> i
21:07:30 <sipa> i'm happy to PR it
21:07:34 <gleb> Great, thank you.
21:07:39 <gleb> I'll focus on the erlay part then
21:07:56 <jnewbery> would minisketch tests run with `make check` in the bitcoin core?
21:08:18 <sipa> they probably should
21:08:32 <sipa> (and that makes it a blocker to not have them run forever...)
21:08:38 <gleb> jnewbery amiti: Let's figure the best way you can help with my erlay refactor in personal messages once I'm ready
21:08:59 <jnewbery> gleb: just leave a comment on the PR when it's ready and I'll take a look at the branch
21:09:06 <amiti> +1
21:09:11 <sipa> +1
21:09:13 <gleb> alright
21:09:59 <jnewbery> that PR is a bit unwieldly at this point. If you're changing the approach and minisketch is going to be split out of it, it might make sense to start a new PR, but you can decide that later
21:10:21 <gleb> jnewbery: I totally agree.
21:10:26 <aj> (+1 on a new PR to avoid all the load mores)
21:10:27 <sipa> yeah
21:10:39 <jnewbery> ok, we have three other topics:
21:10:41 <jnewbery> - Orphan reprocessing (jnewbery)
21:10:49 <jnewbery> - Peer rate-limiting (jnewbery)
21:10:54 <jnewbery> - Dandelion update (ajtowns)
21:11:11 <jnewbery> anyone want to add any quick updates or other topics before we move onto those?
21:11:51 <jnewbery> Dandelion update sounds like it might be the quickest, so maybe we do that first
21:11:59 <jnewbery> #topic dandelion update (ajtowns)
21:11:59 <core-meetingbot> topic: dandelion update (ajtowns)
21:12:12 <aj> oh, i was happy for it to be the if-we-had-time
21:12:14 <aj> anyhoo
21:12:58 <aj> we were talking about dandelion last week, and maybe have some ideas about how to do it without needing a separate stempool. but it was pointed out there was an idea to do a -lite variant, that only stems for a single hop
21:13:26 <aj> that has weaker privacy support, but doesn't need new p2p messages or a separate mempool, so should be much easier to implement
21:13:45 <glozow> does one-hop work? couldn't you tell where a tx originates if you knew they were one-hopping to you?
21:14:01 <glozow> idk if i'm missing something
21:14:02 <aj> i've been chatting on twitter with gulia and she's updated her sims
21:14:03 <gleb> do you make a new connection for one-hop, or pick from existing conns?
21:14:54 <jnewbery> I think if an attacker made multiple connections to you, they could tell if you're only relaying a transaction to a single peer
21:14:58 <aj> glozow: one-hop stem == pick one or two outbound peers and send your tx to them; when you receive a tx always flood it to everyone. so you don't immediately know if a tx was stemmed/flooded to you (and hence don't need different messages)
21:15:18 <aj> jnewbery: if an outbound connects back to you as an inbound, yeah
21:15:31 <aj> jnewbery: (you don't stem to inbounds to make that harder, i think)
21:15:57 <jnewbery> ah, only choose from outbounds
21:16:02 <aj> https://twitter.com/giuliacfanti/status/1362963585471815680 is the twitter thread, and has some graphs
21:16:38 <aj> it looks to me like -lite is a signficant enough improvement that it's probably worth tryng, and dandelion++ proper is enough of an improvement on that that it's still worth thinking about if we can make it feasible
21:16:38 <prayank> aj: I am also trying to resolve conflicts and add Dandelion code (from BIP implementation link) in current master branch. I wasn't even aware you are working on it because nobody informed on IRC, Github or SE when we discussed Dandelion. I will read the Twitter thread and DM you later.
21:17:00 <sipa> prayank: dandelion lite has basically nothing to do with dandelion (in terms of implementation complexity)
21:17:08 <aj> prayank: there's a link in that twitter thread to the irc conversation last week
21:17:10 <gleb> aj: Erlay does something really similar to lite, actually.
21:17:12 <glozow> i don't think the bip is updated for dandelion++
21:17:14 <glozow> is it?
21:17:21 <prayank> sipa: Okay
21:17:21 <sipa> the bip is dandelion++ afaik
21:17:36 <sipa> my impression from dandelion lite is that it's basically 1% of the work to get 80% of the benefits (under vaguely reasonable assumptions)
21:18:10 <aj> sipa: looks more like 40%-50% of the benefits to me
21:18:16 <sipa> okay.
21:18:16 <ariard> so the model is alice initial-broadcast to bob, it's testmempoolaccepted to not let any fingerprint in bob's mempool and stems to caroll, an outbound?
21:18:39 <glozow> i think bob floods, no?
21:18:50 <lightlike> would it be either dandelion or erlay, or would both work together?
21:18:51 <aj> for lite, bob floods
21:18:58 <sipa> there is no stempool in lite, right? you just remember in the wallet itself, and the rebroadcast uses the full broadcast
21:18:59 <ariard> okay gotcha
21:19:06 <gleb> lightlike: they should work together just fine
21:19:16 <glozow> what if bob black-holes it?
21:19:22 <glozow> doesn't relay it, i mean
21:19:40 <sipa> glozow: rebroadcast takes care of it, just like in dandelion (correct me if i'm wrong, aj, i'm going from very vague memory)
21:19:49 <aj> glozow: you hit the wallet rebroadcast timer and do a flood, probably
21:19:56 <glozow> doesn't rebroadcast not run for 12 hours at least?
21:19:58 <jnewbery> can you summarise what the 40-50% benefit is?
21:20:01 <aj> sipa: i don't think those details are really specced anywhere
21:20:20 <gleb> black holes also can be detected and disconnected after one occasion.
21:20:34 <aj> jnewbery: the statistics used are "precision" and "recall" which measure how likely an attacker is to be able to pinpoint the originator of a tx
21:21:18 <jnewbery> why is relaying to one outbound peer better than relaying to 2, or 8?
21:21:30 <sipa> glozow: that'd need to be adjusted then; iirc dandelion has a delay of just a few seconds
21:22:05 <gleb> jnewbery: other 7 of your conns + inbounds have worse idea that it originated from you
21:22:15 <gleb> Rather than when you relay to all of them
21:22:28 <amiti> I think an implementation of dandelion lite would want to add logic for checking if the txn successfully relayed / a quicker rebroadcast if not.
21:22:35 <aj> jnewbery: stemming to one outbound peer is what's modelled in the sim and paper; i don't think it's clear if there's a best value to use
21:22:42 <glozow> sipa: sorry i meant, i think currently rebroadcast is on 12-hour-ish timer, but dandelion++ spec has a several second timer. trying to wrap my head around what needs to be implemented for dandelion lite, perhaps would need to have a timer for rebroadcast-just-incase
21:23:07 <ariard> amiti: quite easy by probing your own mempool to see if you get an announcement back?
21:23:15 <amiti> yup, exactly
21:23:17 <gleb> jnewbery: oh sorry, I guess you ask about the exact choice, yeah, 2 could be better than 1..
21:23:25 <amiti> that just doesn't exist yet
21:23:56 <gleb> glozow: I was also wondering if rebroadcast here should happen in 10 seconds
21:24:07 <sipa> glozow: this would be a separate rebroadcast mechanism i believe
21:24:09 <gleb> I don't see why we should wait 12 hours?
21:24:24 <amiti> aj: is it easy to run the simulation with 2 outbounds and compare?
21:24:26 <sipa> because the dandelion lite "stem" relay can't insert into the mempool
21:24:51 <glozow> gleb: I mean the current rebroadcast behavior on master, without adding any dandelion stuff
21:25:10 <ariard> i think the rebroadcast should be considered in function of opening a one-shot for the connection
21:25:29 <aj> amiti: the sim chooses an anonymity graph with 4 outbounds for each node, and selects one of those outbounds for relay. changing 4 to 2 or 8 is easy, but selecting more than one outbound requires code changes...
21:25:39 <gleb> ariard: one shot wouldn't work at all, unless nodes don't do that for foreign transactions?
21:25:48 <gleb> because it's obvious one-shot is a tx source
21:25:51 <gleb> unless tor
21:26:17 <aj> gleb: yeah, tor or i2p for oneshot
21:26:45 <amiti> aj: gotcha
21:27:00 <gleb> aj: sorry, is this relevant? Are we talking about oneshot over tor as a way to do d lite?
21:27:22 <ariard> gleb: don't we already assume bob has an easier job to guess alice is the source if you mass-connect?
21:27:53 <gleb> ariard: Sure, but lite would help against that even without one-shot tor
21:28:13 <aj> gleb: i thnk the idea is dandelion-lite should work even if your node doesn't do tor/i2p at least. (people talk about lots of things :)
21:28:37 <gleb> aj: without oneshot then. oneshot without tor doesn't work.
21:28:43 <aj> gleb: yep
21:29:26 <jnewbery> aj: do you need help with anything? Would you like people to review a proposal or something else?
21:30:05 <aj> jnewbery: no, just wanted to update people on what's going on. i don't have a particular plan on what's next at this point
21:30:15 <ariard> gleb: could you do one shot without tor for a low % of foreign transactions ?
21:30:18 <amiti> aj: so do I have this right that your current impression that we could implement lite without any protocol changes, code not being too invasive, and get ~40-50% of benefits? what are next steps?
21:30:34 <amiti> oh, you just answered part of that
21:30:35 <gleb> I'd be willing to help. And as a separate thing, aj, we should see how to marry it with erlay in practice, once you reach that point.
21:31:27 <gleb> ariard: that's something was never discussed. I see that as a measure *on top*, but I'd not rely on this solo.
21:31:42 <aj> amiti: yes, i think that's right. not sure if more sims are worth doing first; otherwise figuring out how to be able to stem to some peers without contaminating how you respond to the peers you don't stem too would probably be the first bit of implementation
21:32:56 <jnewbery> aj: hopefully shouldn't be too difficult to update FindTxForGetData. We've done something similar before
21:33:25 <aj> jnewbery: i think working out the spec would be harder than implementing it...
21:33:41 <sipa> haha
21:33:42 <gleb> ariard: that's a cool idea to add noise against any kind of spying. But i think the problem with oneshot-no-tor is that it's success is a function of how ready we are to dos our own network :)
21:33:43 <jnewbery> yup
21:33:51 <amiti> jnewbery: something similar? what are you thinking of?
21:35:30 <jnewbery> m_recently_announced_invs
21:35:52 <jnewbery> maybe it just works already
21:35:58 <ariard> gleb: yeah I know...kinda some trade-offs we're hitting with new rebroadcast, more noise, more bandwidth
21:37:44 <jnewbery> move on to the next topic?
21:37:48 <aj> sounds good
21:38:04 <jnewbery> #topic Orphan reprocessing (jnewbery)
21:38:04 <core-meetingbot> topic: Orphan reprocessing (jnewbery)
21:38:20 <jnewbery> This is something that recently came up again in #21224
21:38:22 <gribble> https://github.com/bitcoin/bitcoin/issues/21224 | [p2p] Halt processing of unrequested transactions by ariard · Pull Request #21224 · bitcoin/bitcoin · GitHub
21:38:38 <jnewbery> we currently reprocess orphan transactions in the context of the node that provided the parent
21:39:09 <jnewbery> ie node A sends us an orphan transaction, node B sends us its parent, we later process the orphan transaction next time we call ProcessMessages() for node B
21:39:45 <jnewbery> it seems a bit strange that we do this, and aj was proposing we change that as part of, or after, orphan handling is split into txorphange
21:40:25 <ariard> idea would be to assign orphan processing to A only?
21:40:52 <sipa> so that means we may punish the peer that provided parent for an invalid orphan received from someone else?
21:41:06 <jnewbery> that seems like a reasonable change to me. We should either process orphan reprocessing in the context of node A, or in some global context (i.e. call PeerManager.DoGenericWork())
21:41:16 <aj> today, we still lookup the original peer when figuring out who to punish
21:41:29 <jnewbery> sipa: no, we already punish the peer who provided the orphan if it's consensus invalid
21:41:53 <sipa> then what do you mean by "in the context of" ?
21:41:58 <ariard> hmmm I would rather avoid global context where you can trace back and punish dosy peers
21:42:06 <jnewbery> see OrphanTx.frompeer (https://github.com/bitcoin/bitcoin/blob/78effb37f35ff09733e79497bd6b06d355272d79/src/net_processing.cpp#L151-L154)
21:42:24 <jnewbery> sipa: we process the transaction the next time we call ProcessMessages(node B)
21:42:29 <ariard> *can't
21:42:33 <aj> sipa: we process the tx when we call ProcessMessages for peer B at present (because the child tx goes into the orphan work set of whoever provided the parent)
21:42:37 <amiti> I think "in the context of" refers to which node we allocate ProcessMessage time to
21:42:48 <sipa> ah, i see
21:44:24 <aj> the idea would be to move the orphan work sets out of the Peer mapping and into a new map in the txorphanage, which can just be sorted by the frompeer, and an entry selected from it during frompeer's ProcessMessages
21:44:37 <jnewbery> sipa: last time this kind of change was proposed you had concerns about the fact it wouldn't be observationally equivalent: http://www.erisian.com.au/bitcoin-core-dev/log-2020-07-02.html#l-325
21:44:53 <aj> moving the orphan work sets out of Peer also allows g_cs_orphans to be moved into txorphanage and stop being a global
21:45:10 <jnewbery> aj: I like this change a lot :)
21:46:53 <jnewbery> my last proposal was to move orphan reprocessing to a global work queue: ttps://github.com/bitcoin/bitcoin/pull/19364 , but moving it to the work queue of the peer who sent it also seems fine
21:47:05 <amiti> is the core reasoning to prevent the sorta attack mentioned in this comment: https://github.com/bitcoin/bitcoin/pull/21224#issuecomment-781741925, where a peer who sends a valid txn that activates lots of invalid orphans would take up our CPU time instead of the one who will eventually be punished?
21:47:47 <ariard> amiti: I'm not sure the peer who sends a valid txn can be actually the culprit for it
21:48:12 <amiti> ariard: what?
21:48:13 <ariard> a malicious peer, if knowledgeable of tx-relay link between two peers might provoke mempool conflicts to trigger this scenario...
21:48:47 <ariard> le'ts say you have alice connected to bob, and mallory to both of them, you send tx A to alice, tx A' to bob
21:48:58 <sipa> jnewbery: i haven't paid attention to the latest discussion; i just hope the motivation is more than "this results in cleaner code for us" if changes observable behavior
21:49:20 <ariard> you send a set of childrens from tx A, will be relayed to bob and stored as orphan
21:50:54 <ariard> receiving orphans on bob side, should trigger him to fetch again tx A and thus do the work on alice account
21:51:54 <aj> (i think it's "add latency to Alice's transactions" more than "use up Alice's CPU time")
21:52:13 <amiti> aj: ok, yeah, that makes sense
21:52:42 <amiti> ariard: I think you're saying that an honest peer can send a parent to invalid orphans received from a different peer?
21:53:02 <ariard> aj: do we actually have this notion of peer CPU time? I don't think so...
21:53:39 <jnewbery> ariard: not yet. That maybe leads nicely into the next topic
21:53:59 <jnewbery> #topic Peer rate-limiting (jnewbery)
21:54:00 <core-meetingbot> topic: Peer rate-limiting (jnewbery)
21:54:15 <ariard> amiti: orphans can be valid there too, and it can work as received from a different peer but not exactly the scenario I was describing
21:54:18 <jnewbery> Again, this came up in the discussion of #21224
21:54:19 <aj> ariard: Mallort constructs tx A, and invalid children of A: B1, B2, B3, B4, ... Mallory relays B1..Bn to Bob. Mallory relays A to Alice. Once Bob receives A from Alice, he'll have high latency for the next tx from Alice
21:54:19 <gribble> https://github.com/bitcoin/bitcoin/issues/21224 | [p2p] Halt processing of unrequested transactions by ariard · Pull Request #21224 · bitcoin/bitcoin · GitHub
21:55:23 <ariard> amiti: the scenario described by aj is the one you were thinking of, mine orphans are announced to alice (note they're considered as orphan but valid txn by alice)
21:55:29 <ariard> AFAICT
21:56:01 <jnewbery> aj: I agree. It makes perfect sense that we don't slow down processing for Alice because of transactions that Bob relayed
21:56:12 <ariard> *are not considred as orphan (damn english)
21:56:18 <jnewbery> *that Mallory relayed
21:56:22 <aj> ariard: bob and alice will relay A and A' to each other, reject them as double spends, and then Alice will reject the children rather than treat them as orphans because they have a rejected parent, i think?
21:57:01 <ariard> aj: at first sight but you can play with rbf and add a grandparent to A and A' to make it work
21:58:02 <amiti> yeah, the scenario aj described is my understanding of the reasoning behind why we would change which peer context we process a parent in.
21:58:46 <ariard> aj: or if A' has been announced through wtxid-relay are we going to add to rejection filter its txid? orphan parent are fetched through txid
22:00:55 <jnewbery> ok, that's time!
22:00:58 <ariard> aj: I should craft a functional test with the scenario, easier way to debate about it :)
22:01:03 <jnewbery> thanks everyone!
22:01:07 <jnewbery> #endmeeting