--- Log opened Wed Dec 04 00:00:09 2024
00:04 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 265 seconds]
00:06 -!- josie [~josibake@suhail.uberspace.de] has quit [Remote host closed the connection]
00:46 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
00:47 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
01:00 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
01:05 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 255 seconds]
01:17 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
01:17 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
01:18 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
01:22 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 248 seconds]
02:19 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
02:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
02:26 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
02:30 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 245 seconds]
03:16 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
03:16 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
03:19 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
03:19 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
03:24 -!- Netsplit *.net <-> *.split quits: ghost43
03:24 -!- Netsplit *.net <-> *.split quits: greypw1, andrewtoth_
03:40 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
03:40 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
03:40 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
03:44 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
04:04 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
04:04 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
04:05 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
04:05 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
04:07 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
04:08 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
04:10 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 255 seconds]
04:11 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
04:12 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
04:21 -!- Zenton_ [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
04:21 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
04:24 -!- Zenton__ [~Zenton@user/zenton] has quit [Remote host closed the connection]
04:24 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
04:26 -!- Zenton__ [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
04:26 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
04:27 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
04:28 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
04:33 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
04:50 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
04:57 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
04:59 -!- premitive2 [~halloy664@user/premitive2] has joined #bitcoin-core-pr-reviews
05:04 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
05:10 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
05:18 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
05:18 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
05:34 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
05:44 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 246 seconds]
05:56 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
06:01 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 248 seconds]
06:04 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:11 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
06:12 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
06:17 -!- premitive2 [~halloy664@user/premitive2] has quit [Ping timeout: 260 seconds]
06:26 -!- greypw14 [~greypw@user/greypw] has joined #bitcoin-core-pr-reviews
06:27 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
06:35 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:41 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
06:42 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:45 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
06:50 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 272 seconds]
06:59 -!- brunoerg [~brunoerg@187.183.60.117] has quit [Remote host closed the connection]
07:00 -!- Murch[m] [~murch@user/murch] has changed host
07:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c06e:38e7:8fec:a425] has joined #bitcoin-core-pr-reviews
07:02 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
07:05 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
07:05 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
07:06 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 255 seconds]
07:07 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
07:08 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
07:08 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c06e:38e7:8fec:a425] has quit [Ping timeout: 264 seconds]
07:10 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has quit [Quit: Bridge terminating on SIGTERM]
07:10 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has quit [Quit: Bridge terminating on SIGTERM]
07:10 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has quit [Quit: Bridge terminating on SIGTERM]
07:10 -!- Murch[m] [~murch@user/murch] has quit [Quit: Bridge terminating on SIGTERM]
07:10 -!- laanwj [~laanwj@user/laanwj] has quit [Quit: Bridge terminating on SIGTERM]
07:10 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::39] has quit [Quit: Bridge terminating on SIGTERM]
07:10 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 260 seconds]
07:10 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::3a] has joined #bitcoin-core-pr-reviews
07:12 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has joined #bitcoin-core-pr-reviews
07:12 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has quit [Remote host closed the connection]
07:12 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::3a] has quit [Remote host closed the connection]
07:13 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::3b] has joined #bitcoin-core-pr-reviews
07:14 -!- Zenton_ [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
07:14 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
07:14 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has joined #bitcoin-core-pr-reviews
07:19 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
07:20 -!- Murch[m] [~murch@2620:6e:a000:ce11::1b] has joined #bitcoin-core-pr-reviews
07:20 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-core-pr-reviews
07:20 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-pr-reviews
07:21 -!- laanwj [~laanwj@user/laanwj] has joined #bitcoin-core-pr-reviews
07:23 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
07:31 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
07:34 -!- Guest68 [~Guest68@2a01cb008f5349000038837c038a476b.ipv6.abo.wanadoo.fr] has joined #bitcoin-core-pr-reviews
07:45 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
07:45 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
07:47 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
07:49 -!- chinggg [~chinggg@141.5.46.6] has joined #bitcoin-core-pr-reviews
08:04 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
08:06 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
08:07 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:08 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 248 seconds]
08:12 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
08:12 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:20 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
08:23 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
08:23 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:24 -!- halloy6647 [~halloy664@2601:582:c500:b8f0:91a5:1d7:f0ae:35ba] has joined #bitcoin-core-pr-reviews
08:28 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
08:31 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
08:31 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:32 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
08:33 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has joined #bitcoin-core-pr-reviews
08:36 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has quit [Remote host closed the connection]
08:36 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has joined #bitcoin-core-pr-reviews
08:37 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:37 -!- Zenton [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
08:42 -!- Zenton_ [~Zenton@user/zenton] has quit [Ping timeout: 245 seconds]
08:42 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:50 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has joined #bitcoin-core-pr-reviews
08:55 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
08:56 -!- Zenton [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
08:57 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
08:58 -!- Emc99 [~Emc99@212.129.77.21] has joined #bitcoin-core-pr-reviews
08:59 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:00 < glozow> hi
09:00 < chinggg> hi
09:00 < dergoegge> hi
09:00 < marcofleon> hi
09:00 < glozow> #startmeeting
09:00 < monlovesmango> hey
09:00 < Guest68> hi
09:00 < halloy6647> hello everyone
09:00 < danielabrozzoni> hi
09:00 < CosmikDebris> hello
09:00 < glozow> Welcome to PR review club! Feel free to say hi to let us know you're here. Any first-timers?
09:01 -!- halloy6647 is now known as premitive2
09:01 < glozow> We're looking at #31397 today, notes and questions in the usual place: https://bitcoincore.reviews/31397
09:01 < marcofleon> woo!
09:01 < glozow> Did anybody get a chance to review the PR and/or look at the notes?
09:01 < glozow> marcofleon: welcome!
09:02 < chinggg> second-timer here. I created txorphan fuzz target 2 year ago mentored by marco
09:02 -!- premitive2 [~halloy664@user/premitive2] has changed host
09:02 < marcofleon> other marco
09:02 -!- andreadcorreia [~andreadco@181.97.201.81] has joined #bitcoin-core-pr-reviews
09:02 < marcofleon> Yeah I reviewed the PR, read through the commits
09:02 < glozow> chinggg: welcome back :) I think I remember your early package fuzz target
09:02 < glozow> Fantastic
09:02 -!- luisschwab [~luisschwa@2804:18:100:bb02:3a24:e833:f680:4ac4] has joined #bitcoin-core-pr-reviews
09:02 < chinggg> Yeah I also reviewed the code
09:02 < danielabrozzoni> I reviewed the PR, focusing on header files to understand the high-level structure, didn't have time for an in-depth review
09:03 -!- andreadcorreia [~andreadco@181.97.201.81] has quit [Client Quit]
09:03 < instagibbs> hi reviewed all but still chewing on the major commit
09:03 < instagibbs> lot going on there
09:03 < glozow> danielabrozzoni: Great approach! I also often start with headers and tests
09:03 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:03 < glozow> Let's jump in with the questions then. If anybody has their own questions, please feel free to ask at any time.
09:04 < glozow> Define orphan resolution, in your own words.
09:04 < premitive2> It's when a node receives a transaction that contains inputs referencing a transaction it doesn't have and then performs actions to find the parent
09:05 < monlovesmango> when a node tries to request the missing parent transaction for a child transaction it has received
09:05 < chinggg> when downloading tx that missing parents, we need to query the peer again to confirm?
09:05 < marcofleon> getting txs that are orphans to possibly get into the mempool by finding their ancestors. process starts when you get a tx that has missing inputs
09:05 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 265 seconds]
09:06 < glozow> Great answers! Yes, we're trying to find the missing inputs of an unconfirmed transaction. It's called an orphan because it's missing at least one parent.
09:06 < glozow> Prior to this PR, what are the steps for orphan resolution, starting from when we notice that the transaction has missing inputs? Bonus points if you can get code links
09:06 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
09:07 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:07 < luisschwab> We just ask the peer that gave us the orphan transaction for the parent. If he doesn't have it, we can't resolve it.
09:07 < marcofleon> https://github.com/bitcoin/bitcoin/blob/ae69fc37e4fff237a119225061d68f69e6cd61d7/src/node/txdownloadman_impl.cpp#L315C5-L392C10 
09:07 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has quit [Quit: Client closed]
09:07 < glozow> luisschwab: great start. Is it necessarily the case that we won't be able to resolve the orphan if the first peer doesn't respond?
09:08 < glozow> marcofleon: bingo
09:08 < instagibbs> if another peer advertises the parent via INV, we can still ask them for it, or if we get another orphan with the same missing parent, we will try them after a timeout?
09:09 < glozow> instagibbs: yep, that's what I was thinking of
09:09 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has joined #bitcoin-core-pr-reviews
09:09 < glozow> Hope is not lost if the first one fails, but we don't actively retry to resolve this specific orphan.
09:09 < instagibbs> 👍
09:10 -!- andreadcorreia [~andreadco@181.97.201.81] has joined #bitcoin-core-pr-reviews
09:10 < luisschwab> got it
09:10 < marcofleon> is that the  GetChildrenFromDifferentPeer?
09:10 < chinggg> In MempoolRejectedTx, we check if (state.GetResult() == TxValidationResult::TX_MISSING_INPUTS), where we notice that the transaction has missing inputs. The link is already in notes?
09:11 < marcofleon> instagibbs: that part you were talking about i mean
09:12 < glozow> marcofleon: yes kind of! If we receive the parent somehow and it's low feerate, we might pick this orphan back up in `Find1P1CPackage` that way
09:12 < instagibbs> that's specifically a 1P1C relay thing
09:12 < marcofleon> got it
09:12 < instagibbs> I was more thinking about when do we ask for parents which isnt 1p1c per se
09:12 < glozow> But not necessarily - instagibbs is also referring to the case where we just accept the parent normally, and then schedule this orphan for processing https://github.com/bitcoin/bitcoin/blob/39950e148d80eec7ef18ff2858453d34a86c15cb/src/node/txdownloadman_impl.cpp#L299
09:13 < marcofleon> nice, thanks for the link
09:13 < glozow> And when we just happened to download the child before the parent
09:13 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:13 < glozow> What are the ways we may fail to resolve an orphan with the peer we request its parents from? What are some reasons things this may happen, honest or otherwise?
09:14 < glozow> I'm thinking of 3 different ways, if that's a helpful hint
09:14 -!- Guest3 [~Guest3@2803:9800:9008:8277:f18f:b07a:656d:c3fc] has joined #bitcoin-core-pr-reviews
09:14 -!- Zenton_ [~Zenton@user/zenton] has quit [Ping timeout: 265 seconds]
09:14 -!- cian-oL [~cian-oL@89.19.88.41] has joined #bitcoin-core-pr-reviews
09:14 -!- gordo-btc [~gordo-btc@2800:810:542:e25:2814:de32:dbe4:fd8a] has joined #bitcoin-core-pr-reviews
09:14 -!- Guest3 [~Guest3@2803:9800:9008:8277:f18f:b07a:656d:c3fc] has quit [Client Quit]
09:14 -!- jpl [~jpl@2803:9800:9008:8277:f18f:b07a:656d:c3fc] has joined #bitcoin-core-pr-reviews
09:15 < marcofleon> peer just doesn't have it so sends a notfound
09:15 < CosmikDebris> the peer may disconnect, the peer may have evicted the parent
09:15 < glozow> marcofleon: yes!
09:15 < glozow> CosmikDebris: yep!
09:15 < glozow> and a 3rd one?
09:15 < chinggg> malicious peer?
09:15 < marcofleon> announces a fake parent...? something malicious yeah
09:16 < glozow> marcofleon: yes!
09:16 < glozow> actually, there is a 4th
09:16 < glozow> 👀
09:16 -!- ioannis_ [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
09:17 < luisschwab> maybe the request gets blocked by the network along the way?
09:17 < glozow> marcofleon: specifically by "fake parent" I'm thinking the tx with a malleated witness. Given that the txid can be the same, they have responded to our request, but since it's invalid it doesn't help us resolve the orphan.
09:17 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
09:17 < glozow> luisschwab: close enough! I was thinking "you just don't get a response from them" so the request times out.
09:18 < glozow> Can you come up with an attack to prevent a node from downloading a 1p1c package by exploiting today’s orphan resolution behavior?
09:18 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 265 seconds]
09:18 < marcofleon> makes sense
09:19 < marcofleon> The peer could just withhold the parent on purpose right? Because it's the only one we try
09:19 < monlovesmango> malicious actor filling up orphanage?
09:19 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:19 < marcofleon> But I guess you were saying it's still possible to find the parent later on?
09:20 < premitive2> Is there a way to overrun the orphan store with fake child txs from different peers? I know there's a limit to the orphaned txs kept around, but I don't know the conditions in which new orphans can replace old ones
09:20 < glozow> premitive2: we evict randomly. so yes, if you just send lots of orphans, most likely you can get other orphans evicted
09:20 < glozow> marcofleon: yes, that only works if you are the one who sends the orphan. is that something you can try to guarantee?
09:22 < instagibbs> the attacker INV-ing the parent wouldn't stop you from eventually asking the honest relayer, right?
09:22 < marcofleon> you'd have to target the node somehow. but yeah I'm not actually sure how a peer would ensure that they were the first ones to send you the orphan
09:23 < glozow> instagibbs: mhm, they can't stop you from asking
09:23 < glozow> for 1p1c with BIP133 though, people wouldn't announce the parent
09:23 < glozow> because of fee filter
09:24 < glozow> marcofleon: the answer I'm looking for is - they send you the orphan unsolicited :)
09:24 -!- ioannis_ [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
09:24 < glozow> since you already have the tx in orphanage, you ignore everyone else who announces it
09:25 < marcofleon> Got it yeah. Just don't go through the normal process of announcing and waiting for the request
09:25 < marcofleon> and could be an advantage
09:28 < glozow> What is the PR’s solution to this problem?
09:28 -!- Emc99 [~Emc99@212.129.77.21] has quit [Quit: Client closed]
09:28 -!- Emc99 [~Emc99@212.129.77.21] has joined #bitcoin-core-pr-reviews
09:28 -!- cian-oL [~cian-oL@89.19.88.41] has quit [Quit: Client closed]
09:28 < monlovesmango> request parent tx from every peer that send the orphan
09:29 < glozow> let's try to be more specific!
09:30 < chinggg> instead of just querying and waiting for the peer who provided the tx, refactor the code and introduce m_orphan_resolution_tracker to query from multiple peer candidates with some scheduling
09:31 < glozow> yes, we're getting warmer! when we find that a tx has missing inputs, instead of adding the parent to our tx request tracker, what do we do?
09:31 < premitive2> There's also reasonable expirations for orphans and delays https://github.com/bitcoin/bitcoin/pull/31397/files#diff-3fc44df0a49b8a2fa4cb515b41fae470b794c32c93e632edb18ae14e8fcb159dR259
09:33 < instagibbs> we add the orphan itself to a new orphan tx request tracker, so when the timer goes off for that, we "immediately" add the missing parents to the regular request tracker
09:34 < glozow> instagibbs: bingo
09:34 < glozow> Does BIP 331 fix any of this?
09:34 < dergoegge> I was wondering why we need another txrequest tracker instance for this? couldn’t we just keep track of announcers in the orphanage (same as in the PR) and then add requests for the parents to the existing tracker on future announcements?
09:34 -!- cian-oL [~cian-oL@89.19.88.41] has joined #bitcoin-core-pr-reviews
09:35 < glozow> dergoegge: that's an idea. How would you schedule the requests?
09:35 < dergoegge> ideally at the same time
09:35 < glozow> Is there a cost to having another txrequest tracker? It's not that different from adding another std::map
09:35 < glozow> No, I mean, how would you load-balance between peers, bake in preferences, etc.
09:36 < dergoegge> isn't that what the existing tracker does?
09:36 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
09:36 -!- Emc99 [~Emc99@212.129.77.21] has quit [Quit: Client closed]
09:36 < glozow> Oh, you mean adding a new type to the tracker? So we'd have txid type, wtxid type, and orphan?
09:36 -!- cian-oL [~cian-oL@89.19.88.41] has quit [Client Quit]
09:36 -!- Emc99 [~Emc99@212.129.77.21] has joined #bitcoin-core-pr-reviews
09:37 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has quit [Ping timeout: 246 seconds]
09:37 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 272 seconds]
09:37 < glozow> also note that the parent requests are added to the txrequest tracker
09:37 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:39 < dergoegge> I guess I'm wondering why we need the concept of tracking the resolution by orphan id, as opposed to just putting the requests for the parents in the existing tracker
09:39 < glozow> we do put the requests for the parents in the existing tracker
09:39 < glozow> Maybe we are crossing wires?
09:39 < instagibbs> mmmm he's asking why the add to new tracker, then "immediately" add to old one, vs just add to old one, I think
09:40 < dergoegge> yea
09:40 < instagibbs> add to old one with "proper delays"
09:40 < instagibbs> I didn't get far enough in my review to figure this out either 😅
09:40 < glozow> We might have multiple candidates for orphan resolution
09:41 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
09:41 < glozow> Oh I see what you're saying
09:41 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:42 < dergoegge> "multiple candidates" as in same parents different orphan?
09:42 < glozow> Perhaps that could work, where you're treating it as if all of them just announced the missing parents? I don't know how you'd add `ancpkginfo` orphan resolution easily this way though.
09:43 < glozow> different peers same orphan
09:43 < instagibbs> You'd also have to somehow track that you're no longer asking for any parents of an orphan in order to EraseOrphanOfPeer?
09:43 < marcofleon> yeah i was thinking it made sense with GetCandidatePeers. Having another tracker to separate out the orphan reso process
09:44 -!- Emc99 [~Emc99@212.129.77.21] has quit [Quit: Client closed]
09:44 -!- Emc99 [~Emc99@212.129.77.21] has joined #bitcoin-core-pr-reviews
09:45 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has quit [Quit: Client closed]
09:46 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has joined #bitcoin-core-pr-reviews
09:46 < glozow> will think about this idea some more
09:47 < dergoegge> me too 👍
09:47 < glozow> I think it's possible it works? My main questions would be (1) what is the cost of having a second tracker? Because it's the perfect data structure for this. (2) how do we make it extensible to package relay still.
09:48 < instagibbs> imo the cost is mostly an additional structure lying around that needs to stay in sync with other things
09:48 < dergoegge> 1) if we don't need it then it's just extra complexity 2) fair!
09:48 < marcofleon> The fact that there are candidates that be added or not added to that new tracker is why it made sense to me in the first place I guess is what i was saying
09:48 < marcofleon> can be*
09:49 < glozow> (1) shoving it into the existing tracker but needing to have extra logic could also be complexity!
09:49 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has quit [Remote host closed the connection]
09:49 < dergoegge> well in my mind it wouldn't need extra logic but I might be wrong, need to think more
09:49 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has joined #bitcoin-core-pr-reviews
09:49 < instagibbs> proof of code for this I think..
09:49 < glozow> but yeah, I don't like that we need to ensure m_orphanage and m_orphan_resolution_tracker are in sync. that's super fair
09:49 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has joined #bitcoin-core-pr-reviews
09:49 < dergoegge> frfr
09:50 < glozow> yeah let's see what the code would look like
09:50 < marcofleon> fr
09:50 < glozow> fr r r
09:50 < glozow> In this PR, which peers do we identify as potential candidates for orphan resolution, and why?
09:51 < glozow> btw, we're not even halfway through the questions. Lmk if y'all would like another session tomorrow. We can make it happen if there's 3+ people interested.
09:51 < marcofleon> I'm down
09:51 < monlovesmango> I'd be interested
09:51 < instagibbs> +1 if same time
09:51 < dergoegge> +1
09:51 < chinggg> sounds cool. the same time?
09:51 < luisschwab> +1
09:52 < premitive2> +1
09:52 < marcofleon> peers that are potential candidates are ones that are in any state but COMPLETED?
09:53 < glozow> marcofleon: yes, which means all of the peers who announced the transaction (that we still remember)
09:53 < instagibbs> I think it's anyone who INV'd us something we have in orphanage, or directly handed us a tx which ends up being an orphan
09:53 < premitive2> Those that have announced they have an orphan's ancestor?
09:53 < monlovesmango> dumb question but what does INV mean?
09:53 < instagibbs> sorry, sending INV aka inventory message
09:53 < instagibbs> short message "hey I have this txid or wtxid"
09:53 < monlovesmango> youre good, thank you!
09:53 < glozow> sending an INV is sending an "inventory" message containing the hash of something you have (e.g. tx), synonymous with announcing it
09:54 < monlovesmango> perfect that helps a lot thanks!
09:54 < glozow> premitive2: nope. We just presume that if you told us about a tx, you must know about all of its ancestors.
09:54 < instagibbs> remember we tack orphans by wtxid in this PR
09:54 < glozow> What does the node do if a peer announces a transaction that is currently a to-be-resolved orphan?
09:54 < instagibbs> and in amster i guess
09:55 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has quit [Ping timeout: 264 seconds]
09:56 < marcofleon> It checks if that peer is an orphan resolution candidate and if it is it adds it as an announcer
09:56 < marcofleon> and adds the inv to the orphan_resolution_tracker
09:56 < chinggg> "instead of adding it to m_txrequest, remember this peer as a potential orphan resolution candidate"
09:56 < glozow> marcofleon: chinggg: yes!
09:57 < glozow> why is that important? hint: we talked about a potential attack earlier....
09:57 < instagibbs> and its a candidate as long as the peer is still connected, and doesn't have too much in flight, pretty much?
09:57 -!- Zenton [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
09:57 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-pr-reviews
09:57 < glozow> instagibbs: yeah. or until we resolve the orphan
09:58 < instagibbs> right i meant at "OrphanResolutionCandidate" time
09:58 < glozow> oh yes, yes
09:58 < glozow> in the future we can also add logic like "and they haven't already given us 20 orphans"
09:59 < glozow> I think it's really important to consider new announcers as orphan reso candidates, for the case where somebody frontruns and sends you an orphan unsolicited.
10:00 < instagibbs> if honest peer announces first, then attacker sends directly, we won't track as a candidate, right?
10:00 < marcofleon> Having multiple peers just makes it more likely to resolve the orphan it seems to me. And yeah less likely that that attack happens
10:00 -!- sebastianvstaa [~sebastian@dsl-94-229-146-149.pool.bitel.net] has joined #bitcoin-core-pr-reviews
10:00 < glozow> instagibbs: we will track the honest peer as a candidate. because it was an announcer of the orphan
10:00 < instagibbs> I'll re-read :)
10:00 < dergoegge> but it announced before we knew it is an orphan?
10:00 < glozow> yes
10:00 < instagibbs> actually i can write a test for this
10:01 < glozow> there should be tests for this in p2p_orphan_handling.py
10:01 < dergoegge> 🚀
10:01 < instagibbs> noice
10:01 < glozow> I write tests!
10:01 < glozow> Oh, we are out of time.
10:01 < glozow> Let's do the next half of the questions tomorrow
10:02 < glozow> #endmeeting
10:02 < marcofleon> see you tomorrow everyone!
10:02 < monlovesmango> thanks glozow and all! really interesting discussion~
10:02 < premitive2> Thanks for hosting!
10:02 < chinggg> Thanks everyone! Learned a lot today
10:02 -!- Emc99 [~Emc99@212.129.77.21] has quit [Quit: Client closed]
10:02 < dergoegge> thanks glozow!
10:02 < luisschwab> thanks glozow
10:02 -!- premitive2 [~halloy664@user/premitive2] has quit [Quit: premitive2]
10:02 -!- luisschwab [~luisschwa@2804:18:100:bb02:3a24:e833:f680:4ac4] has quit [Quit: Client closed]
10:02 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit []
10:04 < instagibbs> "Test that the node uses all peers who announced the tx prior to realizing it's an orphan" sounds promising
10:04 < glozow> thanks everyone for coming. Also, would 1 hour earlier work for y'all?
10:04 < glozow> If it doesn't work we can do same time. I'll just need to shift something a bit
10:05 < instagibbs> 👌 earlier even better for me
10:08 < chinggg> yes earlier sounds better for me
10:08 < dergoegge> works for me
10:12 < sipa> hi
10:16 -!- chinggg [~chinggg@141.5.46.6] has quit [Quit: Client closed]
10:16 -!- chinggg [~chinggg@141.5.46.6] has joined #bitcoin-core-pr-reviews
10:18 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:18 -!- brunoerg [~brunoerg@2804:14d:5285:8b2a::1001] has joined #bitcoin-core-pr-reviews
10:19 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has quit [Quit: Client closed]
10:21 -!- guest273 [~guest273@pool-108-18-150-77.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:22 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has joined #bitcoin-core-pr-reviews
10:23 -!- guest273 [~guest273@pool-108-18-150-77.washdc.fios.verizon.net] has quit [Client Quit]
10:24 < glozow> hi sipa
10:24 < glozow> Sorry just realized 1 hour earlier doesn’t work oops 😅 we will do the same time
10:27 < instagibbs> rugged
10:27 -!- CosmikDebris [~CosmikDeb@190.210.254.130] has quit [Quit: Client closed]
10:28 -!- jing6 [~jing6@2a00:20:4010:8e7b:d0ac:fdff:feb4:7d47] has joined #bitcoin-core-pr-reviews
10:30 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
10:30 < sipa> glozow: oh, if that was about me, i was just randomly saying hi because apparently a whole meeting happened without me noticing, but it wasn't like i was planning to attend, or knew one was happening today (let alone the time)
10:31 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
10:31 < glozow> Ah no, that was me going back on my earlier offer to meet at 16 utc tomorrow
10:32 < sipa> oh, ok!
10:32 -!- jpl [~jpl@2803:9800:9008:8277:f18f:b07a:656d:c3fc] has quit [Quit: Client closed]
10:39 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
10:40 -!- Guest22 [~Guest22@2800:bf0:179:138:4e51:7d76:5d7e:4911] has joined #bitcoin-core-pr-reviews
10:46 -!- Guest65 [~Guest65@2800:2502:7:7a05:3c68:90ff:febd:819e] has joined #bitcoin-core-pr-reviews
10:46 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
10:47 -!- Guest65 [~Guest65@2800:2502:7:7a05:3c68:90ff:febd:819e] has quit [Client Quit]
10:47 -!- Guest22 [~Guest22@2800:bf0:179:138:4e51:7d76:5d7e:4911] has quit [Quit: Client closed]
10:49 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews
10:52 -!- jing6 [~jing6@2a00:20:4010:8e7b:d0ac:fdff:feb4:7d47] has quit [Read error: Connection reset by peer]
10:54 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
11:04 -!- Guest68 [~Guest68@2a01cb008f5349000038837c038a476b.ipv6.abo.wanadoo.fr] has quit [Quit: Client closed]
11:05 -!- andreadcorreia [~andreadco@181.97.201.81] has quit [Ping timeout: 240 seconds]
11:06 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-pr-reviews