--- Log opened Wed Aug 04 00:00:29 2021
00:29 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
00:31 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:42 -!- Talkless [~Talkless@mail.dargis.net] has quit [Read error: Connection reset by peer]
00:43 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
00:53 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has joined #bitcoin-core-pr-reviews
01:02 -!- belcher [~belcher@user/belcher] has quit [Remote host closed the connection]
01:06 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
01:18 -!- belcher [~belcher@user/belcher] has quit [Read error: Connection reset by peer]
01:25 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
02:23 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
02:45 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has joined #bitcoin-core-pr-reviews
05:14 -!- muhblockchain [~muhblockc@user/muhblockchain] has joined #bitcoin-core-pr-reviews
08:27 -!- JanB [~janb@2a10:3781:17e:0:4e0:5633:542:feb5] has joined #bitcoin-core-pr-reviews
08:46 -!- RCI [~RCI@88.121.162.133] has joined #bitcoin-core-pr-reviews
08:47 -!- RCI [~RCI@88.121.162.133] has left #bitcoin-core-pr-reviews []
08:58 -!- jlarsson1 [~l@2804:14d:72ad:842b::1000] has joined #bitcoin-core-pr-reviews
09:00 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:29 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-pr-reviews
09:47 -!- raj_ [~raj_@103.77.139.219] has joined #bitcoin-core-pr-reviews
09:48 -!- raj_ [~raj_@103.77.139.219] has quit [Client Quit]
09:48 -!- raj [~raj_@103.77.139.219] has joined #bitcoin-core-pr-reviews
09:50 < jnewbery> hi folks. We'll get started in 10 minutes. Notes and questions for today's meeting are at https://bitcoincore.reviews/22340
09:54 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:58 -!- murch1 [~murch@user/murch] has joined #bitcoin-core-pr-reviews
09:59 -!- BlockHead [~BlockHead@251.sub-174-211-69.myvzw.com] has joined #bitcoin-core-pr-reviews
10:00 < dergoegge> #startmeeting
10:00 < amiti> hi
10:00 < dergoegge> Hi everyone! Welcome to this week's PR Review Club!
10:00 < willcl_ark> hi
10:00 < glozow> hi
10:00 < raj> hello
10:00 < BlockHead> Whats up 
10:00 < jnewbery> hi
10:00 < dergoegge> Feel to say hi to let people know you are here (lurkers are also welcome)
10:00 < JanB> hi
10:00 < svav> Hi All
10:00 < murch1> Hi
10:00 < dergoegge> Anyone here for the first time?
10:00 < merkle_noob[m]> Hi everyone...
10:00 < larryruane> hi
10:00 < schmidty> hi
10:00 < b10c> hi
10:00 < dergoegge> today we are looking at #22340 - Use legacy relaying to download blocks in blocks-only mode
10:00 < lightlike> hi
10:01 < JanB> firstimer , will be watching only for this time
10:01 < dergoegge> notes and questions are in the usual place: https://bitcoincore.reviews/22340
10:01 < theStack> hi
10:01 < jnewbery> JanB: welcome :)
10:01 < glozow> welcome JanB :D
10:01 < BlockHead> also my 1st time
10:01 < dergoegge> JanB: welcome!
10:01 < dergoegge> we have a couple of prepared questions but feel free to jump in at any point if you have any questions or points you want to add
10:01 -!- Azorcode [~Azorcode@186-88-143-193.genericrev.cantv.net] has joined #bitcoin-core-pr-reviews
10:01 < jnewbery> BlockHead: Welcome!
10:01 -!- murch1 is now known as murchandamus
10:01 -!- thebatzuk [~thebatzuk@201.174.173.234] has joined #bitcoin-core-pr-reviews
10:01 < Azorcode> Hello Everyone
10:01 < JanB> tnx :) 
10:02 < dergoegge> Ok lets get started, Who had a chance to review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
10:02 < murchandamus> n
10:02 < b10c> n
10:02 < amiti> started reviewing, concept ACK! 
10:02 -!- observer11 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
10:02 < dergoegge> BlockHead: Welcome!
10:02 < raj> initial pass. Concept ACK.. 
10:02 < theStack> y, concept ACK
10:02 < larryruane> review y, tested n, ACK
10:02 < svav> n
10:02 < glozow> concept ACK, needs a functional test in p2p_compactblocks_hb.py imo
10:02 < murchandamus> Sounds like a concept ack though
10:02 < lightlike> concept ACK
10:02 < amiti> yeah agree
10:02 < jnewbery> reviewed && ACKed
10:02 < raj> glozow, +1.. 
10:02 < willcl_ark> ACK from me
10:03 < amiti> (agree with glozow)
10:03 < dergoegge> glozow: good point, i agree
10:03 -!- RandyMcMillan [~RandyMcMi@47.205.7.87] has joined #bitcoin-core-pr-reviews
10:03 < dergoegge> First question: What is the sequence of messages used in legacy and compact block relaying?
10:03 < willcl_ark> Yeah I also thought a test would be nice, to avoid a future change inadvertantly reverting this nice win :)
10:04 < amiti> I started tinkering with the functional test, but I'm getting surprising results. I thought one difference would be a blocksonly node sending sendcmpct with 0 vs 1, but that's not what I'm getting in the tests 🤔
10:04 < amiti> but maybe we can get to that later :) 
10:05 < dergoegge> amiti: interesting, we can get to that later
10:05 < larryruane> for the sequence, there's a really nice diagram in the PR description
10:06 < BlockHead> larryruane yeah i think that sequence diagram is taken from BIP 152 doc
10:06 < glozow> both would do headers first,
10:06 < glozow> low-bandwidth compact block would request GETDATA(CMPCT_BLOCK) and get a compact block and then do GETBLOCKTXN?
10:06 < glozow> legacy would do a GETDATA(BLOCK) and then a BLOCK
10:06 < glozow> high-bandwdith compact block sends a compact block straight away, with coinbase prefilled?
10:07 -!- ami76 [~ami@76.126.202.7] has joined #bitcoin-core-pr-reviews
10:07 < dergoegge> glozow: yes, i think the coinbase is prefilled
10:07 < jnewbery> larryruane: the sequence diagram is from BIP152: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki
10:08 < glozow> headers first for low bandwidth compact block and for legacy*?
10:08 -!- dappsar [~dappsar@181.229.170.62] has joined #bitcoin-core-pr-reviews
10:08 < dergoegge> glozow: i think both inv and headers is possible but unsure
10:08 -!- ami76 [~ami@76.126.202.7] has quit [Client Quit]
10:08 < larryruane> i did have a question about case C, low bandwidth relaying ... since node B is sending a getdata(CMPCT) message, why is it necessary for that node to announce ahead of time that it wants to use this mode (the sendcmpct(0) message? 
10:09 < glozow> larryruane: i think you'd need a version of bitcoin client that understands compact block p2p messages
10:09 < larryruane> so for example, let's say node B doesn't send the sendcmpct(0) message ... then later sends a getdata(CMPCT)? is that just a protocol error?
10:10 < dergoegge> larryruane: yes the peer would not respond with a cmpctblock message
10:10 < lightlike> GETBLOCKTXN is not always sent - if we have all the txes in our mempool, would it be skipped?
10:10 < murchandamus> IIRC, only really old nodes would announce blocks with INV messages, any newer nodes would always announce it with the header 
10:10 < larryruane> glozow: okay, but if it's sending a getdata(CMPCT), doesn't that indicate that it understands compact block p2p messages?
10:10 < BlockHead> glozow it looks like headers/inv are sent via legacy and low band. and not highband.
10:11 -!- ami85 [~ami@172.58.94.182] has joined #bitcoin-core-pr-reviews
10:11 < dergoegge> lightlike: i think it is sent and it requests all the txs that are missing
10:11 < theStack> ad legacy relaying diagram: what does it depend on whether a peer is notified via headers or via inv? (according to the protocol documentation, headers is only sent in response to getheaders: https://en.bitcoin.it/wiki/Protocol_documentation#headers)
10:11 < jnewbery> dergoegge: yes, Bitcoin Core will only prefill the coinbase. There's a TODO in the code to make it prefill transactions that it didn't have in its mempool as well: https://github.com/bitcoin/bitcoin/blob/4f1a75b1aa9402e62bc2ed3e0296e4fba81254e4/src/blockencodings.cpp#L23-L28
10:12 < glozow> BlockHead: ye!
10:12 < lightlike> dergoegge: yes, but what if there are no txs missing (because we have them all in our mempool)?
10:12 < glozow> lightlike: then we don't send any GETBLOCKTXN
10:12 < jnewbery> murchandamus: we'll announce blocks using INV to any peers that don't send us a `sendheaders` during version handshake
10:12 -!- ami85 [~ami@172.58.94.182] has quit [Client Quit]
10:12 < murchandamus> jnewbery: Okay, thanks
10:13 < dergoegge> lightlike: oh right, i am not sure in that case but i guess it could be omitted
10:13 -!- RandyMcMillan10 [~RandyMcMi@172.58.173.47] has joined #bitcoin-core-pr-reviews
10:13 < glozow> lightlike: also, could get them from `vExtraTxnForCompact`
10:13 -!- RandyMcMillan10 [~RandyMcMi@172.58.173.47] has quit [Client Quit]
10:13 < dergoegge> Ok next question: Why does compact block relay waste bandwidth for blocksonly nodes during block download? How much bandwidth is wasted?
10:14 -!- RandyMcMillan20 [~RandyMcMi@172.58.173.47] has joined #bitcoin-core-pr-reviews
10:14 < lightlike> we can also revert to inv-mode - at least, this seems to happen sometimes in the functional tests intermittently, when the CI has strange delays for some reason
10:14 < glozow> larryruane: I think we usually disconnect a peer that sends a message we don't expect? not always tho, would need to look at what BIP152 says
10:14 < jnewbery> lightlike: we only send a `getblocktxn` if we weren't able to reconstruct the block from our mempool/extra txns: https://github.com/bitcoin/bitcoin/blob/4f1a75b1aa9402e62bc2ed3e0296e4fba81254e4/src/net_processing.cpp#L3522-L3535
10:15 -!- thebatzuk [~thebatzuk@201.174.173.234] has quit [Quit: Connection closed]
10:15 < larryruane> dergoegge: is it because the node will need to request a bunch of tx that we would have gotten with the full block?
10:15 < BlockHead> dergoegge block only nodes don't have a mempool, so it always needs all the detail about new blocks
10:16 < dergoegge> larryuane: yes the requesting of the txs adds a bit of overhead but there is also another message that causes some waste
10:17 < jnewbery> larryruane: I may be mistaken, but it looks like we'll respond to a getdata(cmpctblock) even if the peer hasn't sent us a sendcmpct message: https://github.com/bitcoin/bitcoin/blob/4f1a75b1aa9402e62bc2ed3e0296e4fba81254e4/src/net_processing.cpp#L1849-L1866
10:17 -!- RandyMcMillan [~RandyMcMi@47.205.7.87] has quit [Ping timeout: 256 seconds]
10:18 < dergoegge> BlockHead: yes blocksonly nodes don't have a mempool
10:18 -!- RandyMcMillan20 [~RandyMcMi@172.58.173.47] has quit [Client Quit]
10:18 < lightlike> i think most of the overhead is them sending us all the short-ids for the txes, when we'd request all of them anyway. that is unnecessary
10:18 -!- RandyMcMillan [~RandyMcMi@172.58.173.47] has joined #bitcoin-core-pr-reviews
10:18 < dergoegge> lightlike: exactly
10:19 < dergoegge> the unnecessary shortids are in the cmpctblock and getblocktxn message
10:19 < jnewbery> larryruane: I think you can think of a sendcmpct(0, version) to mean "I can provide compact blocks" and a sendcmpct(1, version) to mean "I want you to use HB compact blocks to announce new blocks"
10:19 -!- RandyMcMillan [~RandyMcMi@172.58.173.47] has quit [Client Quit]
10:20 -!- ami1 [~ami@76.126.202.7] has joined #bitcoin-core-pr-reviews
10:20 -!- BlueMoon99 [~BlueMoon@189.130.47.56] has joined #bitcoin-core-pr-reviews
10:20 < dergoegge> one thing to note here is that bandwidth is only wasted when downloading blocks
10:20 < dergoegge> which ties into the next question: Can and should a blocksonly node still serve compact blocks to their peers?
10:20 < lightlike> dergoegge: Are you sure? I thought they do have a mempool as well, it is just not updated via p2p? for example, if I restart a normal node with a full mempool into blocks-only mode, the mempool will still be full?!
10:21 -!- RandyMcMillan [~RandyMcMi@172.58.173.47] has joined #bitcoin-core-pr-reviews
10:21 < larryruane> jnewbery: +1 thanks
10:21 < jnewbery> lightlike: yes, you're right. There is still a mempool, but the node won't request transactions from peers when it receives an inv
10:21 < amiti> lightlike: that's true, but rare right? you'd have a mempool initially, but then after some time it'd likely clear out? 
10:22 < lightlike> amiti: yes, I agree. with time, it will clear out.
10:22 < amiti> dergoegge: yes, I think blocksonly nodes serving compact blocks makes sense 
10:22 -!- BlueMoon99 [~BlueMoon@189.130.47.56] has quit [Quit: Connection closed]
10:22 < jnewbery> I don't think there's currently a config option to switch the mempool off entirely, although it shouldn't be too much work to implement that now that so much work has been done to separate out the components
10:22 -!- Blue_Moon333 [~Blue_Moon@189.130.47.56] has joined #bitcoin-core-pr-reviews
10:23 < theStack> i'd also say serving compact blocks from blocksonly nodes makes sense
10:23 < larryruane> but even in blocks-only, don't i need a mempool for transactions that i'm initiating?
10:23 < glozow> larryruane: yes, you do. which is why you have one i think
10:24 < amiti> larryruane: you can initiate transactions in blocksonly node but its not recommended. its a dead give away that they are your own =P
10:24 -!- Ami24 [~Ami@76.126.202.7] has joined #bitcoin-core-pr-reviews
10:24 < dergoegge> amiti theStack: yes so blocksonly nodes can and should still serve compact blocks since they really only the entire block to be able to do that
10:24 < larryruane> amiti: glozow: gotcha thanks makes sense
10:24 -!- jomsox [~jomsox@189.169.216.129] has joined #bitcoin-core-pr-reviews
10:25 < dergoegge> btw. we forgot a part of the previous question. "how much bandwidth is wasted?" these two comments have some data: https://github.com/bitcoin/bitcoin/pull/22340#issuecomment-869016710, https://github.com/bitcoin/bitcoin/pull/22340#issuecomment-872723147
10:25 -!- Azorcode [~Azorcode@186-88-143-193.genericrev.cantv.net] has quit [Quit: Connection closed]
10:25 -!- Azorcode [~Azorcode@186-88-143-193.genericrev.cantv.net] has joined #bitcoin-core-pr-reviews
10:25 -!- thebatzuk [~thebatzuk@201.174.173.234] has joined #bitcoin-core-pr-reviews
10:26 < dergoegge> What is PeerManagerImpl::m_ignore_incoming_txs? Where and how does this PR use it to achieve its goals?
10:27 < larryruane> hey in case this may be useful to anyone else, to measure the bandwidth of your local bitcoind, run `sudo iftop -f 'port 8333' in another window (on linux, you may have to apt install it)
10:27 < theStack> m_ignore_incoming_txs it is set to true if the node was started with -blocksonly
10:27 < larryruane> sorry that didn't format right `sudo iftop -f 'port 8333'`
10:28 < dergoegge> larryruane: to collect the data for this PR i used -debug=all and then later parsed the logs
10:28 < larryruane> theStack: that's right https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L1164
10:28 < dergoegge> theStack: correct!
10:29 -!- ami1 [~ami@76.126.202.7] has quit [Quit: Connection closed]
10:30 < lightlike> I think the naming of the variable m_ignore_incoming_txs is a bit misleading. we don't just ignore them, we'll disconnect the peer if they send us txes.
10:31 -!- thebatzuk [~thebatzuk@201.174.173.234] has quit [Quit: Connection closed]
10:31 < jnewbery> lightlike: good point. Maybe m_ignore_tx_announcements would have been more appropriate. 
10:32 < jnewbery> (some discussion of the naming here: https://github.com/bitcoin/bitcoin/pull/20217#discussion_r510099354)
10:33 < amiti> what about m_please_don't_send_me_txns ?? :) 
10:33 < dergoegge> So one thing we do in this PR is not send sendcmpct(1) if m_ignore_incoming_txs=true
10:33 < lightlike> jnewbery: but we seem to disconnect even for sending INVs. maybe just m_blocksonly_mode ?
10:33 < raj> amiti, I like it.. :D
10:33 -!- RandyMcMillan [~RandyMcMi@172.58.173.47] has quit [Ping timeout: 272 seconds]
10:33 < dergoegge> what does that achieve?
10:34 < jnewbery> lightlike: oh yes, you're right that we'll disconnect if they send an INV
10:35 < larryruane> just for us newbies, INV used to be used to announce both blocks and transactions, but now is used only for transactions?
10:36 < jnewbery> (the reason we disconnect is that it's a violation of the protocol. We've sent them fRelay=false in our version message to them, requesting that they don't relay txs to us)
10:36 < willcl_ark> Agree the name could be changed, but I quite like the behaviour, it's better for low-bandwidth nodes to disconnect if people start sending you unsolicited messages, wasting your bandwidth
10:36 < lightlike> larryruane: you are right, i meant tx INVs, there are two types of INVs, and Block INVs are ok in blocksonly mode
10:38 < merkle_noob[m]> Please, I have a question: What is the difference between sending a headers announcement and an INV announcement?
10:38 < sipa> in an INV announcement, you send just the block hash
10:38 < sipa> in a headers announcement, the block header (80 bytes) is sent instead
10:39 < larryruane> notice too that at least by default, we set up a block-relay-only connection to some of our peers, even without the local `-blocksonly` flag ... does that cause `ignores_incoming_txs` to be set to true? 
10:39 < merkle_noob[m]> sipa: Thanks...
10:39 < JanB> dergoegge by not sending sendcmpct(1) we default to Legacy relaying (?)
10:39 < amiti> larryruane: no, -blocksonly is a mode & sets ignore_incomping_txs
10:39 < amiti> but block-relay-only is an attribute of a connection 
10:40 < larryruane> but should the changes this PR is making apply to the latter case too?
10:40 < jnewbery> markle_noob[m]: headers-first syncing was implemented in https://github.com/bitcoin/bitcoin/pull/4468
10:41 < dergoegge> JanB: almost correct, there is a second step to defaulting to legacy relay. by not sending sendcmpct(1) we don't request high bandwidth mode, so our peer won't send us cmcptblock messages to announce blocks.
10:42 < JanB> dergoegge: ah yes, i c 
10:43 < dergoegge> So now that high bandwidth mode is covered what do we need to do for low bandwidth mode?
10:43 < amiti> larryruane: I don't think so. I could be running a node with a full mempool and have a block-relay-only connection to you. Just because you don't send me txns doesn't mean I necessarily don't already have them to reconstruct the block from short ids.
10:43 < amiti> with -blocksonly mode, although its possible I have mempool txns based on edge cases, most likely I don't have mempool txns, so will need to get all the transactions
10:44 < raj> dergoegge, we should also ensure not to send sendcmpct(0)?
10:44 < theStack> dergoegge: if we receive an announcement via headers or inv, request the full block rather than compact blocks
10:44 < lightlike> a weird thing is that I think even in blocksonly mode, one has two block-relay-only connections ;)
10:44 < amiti> lightlike: hahhaha, yeah that's true =P 
10:45 < larryruane> amiti: yes, you're exactly right, i see now, +1
10:45 < dergoegge> raj: we actually need to still send sendcmpct(0) otherwise a peer won't request compact blocks and a blocksonly node still wants to serve those
10:45 < dergoegge> theStack: correct!
10:46 < jnewbery> lightlike: amiti: (I know you know this alredy, but for everyone else) block-relay-only connections also don't gossip addrs, so even in blocksonly mode their behaviour is slightly different from the other connections
10:46 < merkle_noob[m]> jnewbery: Thanks for the link...
10:46 < raj> dergoegge, oh right.. thanks.. 
10:46 < dergoegge> raj: Peers of a blocksonly node don’t request compact blocks if `fSupportsDesiredCmpctVersion=false`. The only place that `fSupportsDesiredCmpctVersion` is set to true is https://github.com/bitcoin/bitcoin/blob/6dfee13f650521f7542df0926aff01af9ac6a328/src/net_processing.cpp#L2712-L2717
10:47 < dergoegge> amiti: since we are talking about sendcmpct what did you observe in your tests?
10:48 < JanB> dergoegge: that's done by the extra check added on line 2125 ? (to request the full block)  
10:48 < theStack> so if i see that correctly, at the point of the diff where the second change occurs, the GETDATA message is already prepared to request the full block, and we add an additional condition (!m_ignore_incoming_txs) to when to modify the message to request compact blocks
10:50 < jnewbery> theStack: right - there's no point in requesting a compact block if we don't have transactions in our mempool
10:50 < amiti> dergoegge: even with the guard to MaybeSetPeersAsAnnouncing... commented out, the sendcmpct announce bool was set to False for a blocksonly node. I thought this is what that clause would change (so, true on master, false on PR). but I might be missing something in my test setup or my understanding =P  
10:50 < amiti> https://github.com/amitiuttarwar/bitcoin/commit/9053613f4c4131615c2a395da9d33f47dd8e4720
10:50 < dergoegge> JanB: yes so if m_ignore_incoming_txs = true then we don't send getdata(CMPCT) and instead send a normal getdata(BLOCK)
10:50 < larryruane> theStack: looks like to me too, and also I found it interesting (not changed by this PR) that only the first entry in the CInv vector needs to say MSG_CMPCT_BLOCK ... all the others can still say MSG_BLOCK
10:51 < lightlike> larryruane: One more thought about your earlier question: I think the main reason for having block-relay-only connections is to not be subjected to privacy issues with tx and addr relay. By allowing compactblock downloading, you do reveal something about your mempool to them which you otherwise wouldn't (which txes of the block you still need), but I think it's not really possibly to abuse this, because creating valid blocks we'd 
10:51 < lightlike> download from you requires POW.
10:52 < dergoegge> amiti: sendcmpct is send multiple times and the first time it is send the announce flag defaults to false
10:52 < dergoegge> https://github.com/bitcoin/bitcoin/blob/6dfee13f650521f7542df0926aff01af9ac6a328/src/net_processing.cpp#L2678
10:52 < dergoegge> maybe that is what you are seeing?
10:52 < larryruane> lightlike: +1
10:53 < theStack> jnewbery: yes that makes sense
10:53 -!- BlockHead [~BlockHead@251.sub-174-211-69.myvzw.com] has quit [Quit: Connection closed]
10:53 < amiti> I see two sendcmpct messages being sent & both have announce = false, whether or not the m_ignore_incoming_txs guard is set 
10:53 < theStack> larryruane: hm is it even possible to mix different types within an INV? (i have to make myself more familiar with the protocol messages...)
10:53 < jnewbery> amiti: we'll only send a sendcmpct(hb=true) to a peer if that peer has sent us a valid block at the tip
10:54 < amiti> ohhh
10:54 < jnewbery> during version handshake we'll send two sendcmpct(hb=false) to the peer to let them know we support version 1 and version 2 compact blocks
10:54 < dergoegge> jnewbery: oh yes that is also something that is saw in my manual testing
10:54 < jnewbery> (plug: https://github.com/bitcoin/bitcoin/pull/20799 means we can remove version 1 compact blocks)
10:55 < amiti> ok so in order to see the change in behavior, I should have the p2pconn send the blocksonly node a valid block at the tip in the test setup? 
10:55 < dergoegge> in the interest of time lets move on: What do you think of Gleb’s comments on the usage of sendrawtransaction? Can you think of other exceptions in which a blocksonly node would still want to download compact blocks?
10:55 < dergoegge> gelb's comment: https://github.com/bitcoin/bitcoin/pull/22340#issuecomment-875542706
10:55 < jnewbery> but we only send sendcmpct(hb=true) if the peer is the first to provide a valid block at the tip. It's in the BlockChecked callback in the validation interface
10:55 < jnewbery> amiti: yes, that should do it as long as the node is out of IBD
10:56 < amiti> jnewbery: ok! that helps a lot, thanks :) 
10:58 < amiti> dergoegge: I think its possible but highly unlikely 
10:58 < lightlike> dergoegge: if a node in blocksonly mode somehow receives up-to-date txes from somewhere else. I don't really think that the scenario by gleb sounds very probable.
10:58 < jnewbery> dergoegge: I think it's unlikely that anyone is using the node in this way
10:59 < dergoegge> lightlike: yeah i can't think of another way for a node to receive all txs besides sendrawtransaction
10:59 < dergoegge> i also think gleb's scenario is pretty unlikely
10:59 < dergoegge> if you find other exceptions please comment on the PR :)
11:00 < dergoegge> #endmeeting
11:00 < lightlike> and even if that was the case somewhere, it's not like it would break anything - it would just add some extra bandwidth for this particular user.
11:00 < larryruane> just to confirm myself, `sendrawtransaction` doesn't involve the local wallet at all, right? It's just an RPC, someone else has done all the work to construct the tx
11:00 < theStack> thanks for hosting!
11:00 < dergoegge> Thanks for coming everyone! this was fun as per usual!
11:00 < amiti> dergoegge: thanks for a great meeting :) 
11:00 < willcl_ark> thanks dergoegge
11:00 < jnewbery> Great meeting. Thanks for the PR and for hosting dergoegge!
11:00 < dergoegge> feel free to stick around to discuss
11:00 < larryruane> thanks dergoegge, that was great!
11:00 < lightlike> thanks dergoegge!
11:00 < glozow> thanks dergoegge! :)
11:00 < raj> dergoegge, thanks for hosting.. was a good session. :)
11:01 < JanB> Thanks dergoegge ! 
11:01 < dergoegge> lightlike: i agree
11:01 < larryruane> lightlike: +1
11:01 < dergoegge> larryruane: yeah the node can submit any random txs that way
11:01 < larryruane> very different from `sendmany` (IIUC)
11:02 < larryruane> `sendmany` must select UTXOs, and also sign, so needs the (local) wallet
11:04 < svav> Thanks
11:05 < JanB> Nice way to be introduced to reviewing the PR's, thanks all. See you next week. 
11:06 < larryruane> JanB: +1
11:10 < merkle_noob[m]> Thanks to dergoegge and everyone else for the meeting...
11:13 -!- observer11 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Quit: Connection closed]
11:13 -!- Azorcode [~Azorcode@186-88-143-193.genericrev.cantv.net] has quit [Quit: Connection closed]
11:13 -!- Blue_Moon333 [~Blue_Moon@189.130.47.56] has quit [Quit: Connection closed]
11:15 -!- jomsox [~jomsox@189.169.216.129] has quit [Quit: Connection closed]
11:20 -!- dappsar [~dappsar@181.229.170.62] has quit [Quit: Connection closed]
11:30 -!- raj [~raj_@103.77.139.219] has quit [Ping timeout: 250 seconds]
11:31 -!- jlarsson1 [~l@2804:14d:72ad:842b::1000] has left #bitcoin-core-pr-reviews [Konversation terminated!]
12:01 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
12:06 -!- JanB [~janb@2a10:3781:17e:0:4e0:5633:542:feb5] has quit [Remote host closed the connection]
12:59 -!- lightlike [~lightlike@user/lightlike] has left #bitcoin-core-pr-reviews [Leaving]
13:09 -!- Cocasti [~Cocasti@106-146-17-190.fibertel.com.ar] has joined #bitcoin-core-pr-reviews
14:16 -!- takinbo [~takinbo@user/takinbo] has quit [Quit: No Ping reply in 180 seconds.]
14:17 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Ping timeout: 244 seconds]
14:17 -!- takinbo [~takinbo@user/takinbo] has joined #bitcoin-core-pr-reviews
14:19 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews
15:02 -!- Cocasti [~Cocasti@106-146-17-190.fibertel.com.ar] has quit [Quit: Connection closed]
15:04 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
15:36 -!- davterra [~davterra@143.198.56.186] has quit [Remote host closed the connection]
16:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 244 seconds]
17:59 -!- Ami24 [~Ami@76.126.202.7] has quit [Quit: Connection closed]
18:14 -!- davterra [~davterra@143.198.56.186] has joined #bitcoin-core-pr-reviews
18:58 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has quit [Quit: Connection closed for inactivity]
19:03 -!- muhblockchain [~muhblockc@user/muhblockchain] has quit [Read error: Connection reset by peer]
19:25 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
19:28 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
--- Log closed Thu Aug 05 00:00:29 2021