--- Day changed Wed Mar 31 2021
00:47 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []     
00:47 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews     
00:47 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]     
00:47 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
01:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
01:12 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
01:12 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
01:12 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
02:19 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 276 seconds]     
02:23 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews     
02:30 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
02:42 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
02:46 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
02:48 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews     
02:50 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Remote host closed the connection]     
02:51 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews     
03:14 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
03:20 -!- Lane58Glover [~Lane58Glo@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:25 -!- Lane58Glover [~Lane58Glo@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]     
03:45 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
03:45 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
03:51 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds]     
03:57 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
04:17 -!- csknk [~csknk@unaffiliated/csknk] has quit [Ping timeout: 260 seconds]     
04:20 -!- michaelfolkson2 is now known as michaelfolkson     
05:33 -!- belcher_ is now known as belcher     
05:58 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
06:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
06:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
06:59 -!- stortz [bb3fa18c@unaffiliated/stortz] has joined #bitcoin-core-pr-reviews     
07:06 -!- stortz [bb3fa18c@unaffiliated/stortz] has quit [Quit: Connection closed]     
07:21 -!- jadi [~jadi@178.131.26.196] has quit [Read error: Connection reset by peer]     
07:31 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews     
07:42 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
07:43 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
08:12 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews     
08:14 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
08:15 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
08:23 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has joined #bitcoin-core-pr-reviews     
08:26 -!- csknk [~csknk@unaffiliated/csknk] has quit [Ping timeout: 240 seconds]     
08:32 -!- ivanacostarubio [~ivan@189.172.170.168] has joined #bitcoin-core-pr-reviews     
08:34 -!- tkc_ [a29af3ea@162.154.243.234] has joined #bitcoin-core-pr-reviews     
08:46 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
08:51 -!- tkc_ [a29af3ea@162.154.243.234] has quit [Quit: Connection closed]     
08:54 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
08:54 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
08:55 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
08:56 -!- tkc_ [a29af3ea@162.154.243.234] has joined #bitcoin-core-pr-reviews     
09:01 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
09:02 -!- tkc [~tkc_@162.154.243.234] has joined #bitcoin-core-pr-reviews     
09:02 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:04 < sishir> hi     
09:05 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Client Quit]     
09:05 < glozow> in an hour right?
09:05 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:05 < tkc_> so in an hour?  not now?
09:06 < svav> In an hour I believe
09:06 < glozow> right now it is 16 UTC
09:06 < glozow> so 1 more hour
09:07 < tkc_> is see now--time change. :)
09:07 < svav> Gives you an extra hour to work everything out :)
09:07 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
09:08 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Client Quit]     
09:08 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Quit: Konversation terminated!]     
09:09 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
09:10 < tkc_> I'll need more than an hour...
09:20 -!- lightlike [~lightlike@p200300c7ef2d33009555da3eb4157696.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:25 -!- tkc_ [a29af3ea@162.154.243.234] has quit [Quit: Connection closed]     
09:25 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
09:29 -!- tkc [~tkc_@162.154.243.234] has quit [Ping timeout: 260 seconds]     
09:32 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
09:37 -!- jadi [~jadi@178.131.26.196] has quit [Ping timeout: 240 seconds]     
09:51 -!- genef [~gene@198.167.192.35] has joined #bitcoin-core-pr-reviews     
09:55 -!- tkc [~tkc_@162.154.243.234] has joined #bitcoin-core-pr-reviews     
09:56 -!- tkc_ [a29af3ea@162.154.243.234] has joined #bitcoin-core-pr-reviews     
09:57 -!- stortz [bb3fa18c@unaffiliated/stortz] has joined #bitcoin-core-pr-reviews     
09:59 -!- petroleum [~petroleum@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10:00 < amiti> #startmeeting
10:00 < jnewbery> hi!     
10:00 < amiti> hi!     
10:00 < glozow> hi     
10:00 < petroleum> hi     
10:00 < ccdle12> hi     
10:00 < genef> hi     
10:00 < svav> hi     
10:00 < tkc_> hi     
10:00 < amiti> welcome everyone!
10:00 < b10c> hi     
10:00 < lightlike> hi     
10:00 < amiti> anyone here for the first time?
10:01 < ivanacostarubio> hi     
10:01 < emzy> hi     
10:01 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
10:01 < amiti> some reminders - all questions are welcome, we're here to learn :)
10:01 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
10:01 < amiti> and feel free to ask them whenever, no need to ask to ask
10:02 < amiti> who got a chance to review the PR this week? (y / n)
10:02 < genef> y     
10:02 < b10c> y     
10:02 < svav> y     
10:02 -!- gniemeyer [~gniemeyer@c-71-198-251-246.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
10:02 < ccdle12> y     
10:02 < jnewbery> (notes and questions here: https://bitcoincore.reviews/21528)
10:02 < jnewbery> y     
10:02 < lightlike> y     
10:02 < amiti> wow lots of review!
10:02 < ivanacostarubio> y     
10:02 < sishir> y     
10:02 -!- sugarjig [d81eb60a@216.30.182.10] has joined #bitcoin-core-pr-reviews     
10:03 < glozow> y     
10:03 < amiti> first question: Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
10:03 < emzy> n     
10:04 < amiti> a good time for general thoughts about the PR :)
10:04 < ccdle12> concept ACK
10:04 < genef> Concept ACK, light code review
10:04 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
10:04 < b10c> concept ack
10:04 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
10:04 < ivanacostarubio> concept ACK.
10:04 < schmidty> y     
10:05 < jnewbery> Concept ACK, approach ACK
10:05 < amiti> would anyone like to summarize the goal of the PR?
10:05 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has left #bitcoin-core-pr-reviews []     
10:05 < amiti> related to question 2: What is an addr black hole? Why is this a concern for addr propagation?
10:05 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
10:05 < svav> Prevent eclipse attacks
10:05 < sishir> in some nodes set of addresses will go in but do not escape, they do not propagate in time
10:05 < ccdle12> reliable propagation of addr announcements
10:06 < amiti> svav: indeed, the goal of good addr relay is to be robust to eclipse attacks, can you describe more about what part specifically this PR contributes to?
10:06 < amiti> sishir, ccdle12: yes!
10:06 < petroleum> Does this PR *reduce the occurrence* of addr blackholes or is it more /reducing addr data propagation overhead/?
10:06 < glozow> i thought of black hole just in relation to our node (they wont forward addrs we send them) and not necessarily that they dont participate in addr relay at all
10:06 < petroleum> seems more the later, to me
10:07 < amiti> glozow: good clarification! yes they could be either
10:07 < amiti> does anyone want to answer petroleum's question ?
10:07 < ivanacostarubio> Make sure we won't send addr messages to peers that won't relay those messages
10:07 < amiti> ivanacostarubio: yup
10:08 < sishir> I thought this feature is not relaying addr at all to block-relay-only nodes and light clients so reduce occurrence?
10:08 < amiti> sishir: exactly
10:08 < amiti> petroleum: does that make sense?
10:08 < petroleum> amiti so the later part of my sentence?
10:08 < glozow> neither
10:08 < petroleum> e.g. communication overhead reduction
10:08 < petroleum> oh     
10:09 < amiti> oh I see what you mean
10:09 < petroleum> I don't see how it's exclusively the later and none of the former (in my original question)
10:09 < amiti> I guess latter, but I'd phrase it differently
10:09 < petroleum> block-relay-only will always be an addr black hole
10:09 < petroleum> got it
10:09 < lightlike> I'd say that it does reduce the occurrence of black holes, because we relay a given ADDR to a limited number of nodes, and those messages that aren't sent to black holes will be sent to other nodes instead.
10:10 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-uknulmwkfwhcrdns] has quit [Ping timeout: 252 seconds]     
10:10 < amiti> lightlike: great description. thanks!
10:10 < petroleum> lightlike yeah good perspective
10:10 < amiti> ok, so lets dig in to how / why
10:10 < amiti> How does Bitcoin Core implement self-announcements? How would you expect a single advertisement to propagate throughout the network?
10:11 < sishir> Q. Does advertising mean that node is putting itself out to get connected to?
10:11 < svav> Periodic self announcement by nodes
10:12 < ccdle12> in SendMessages, our node will check if the peer can relay addrs, we are not in IBD and if the `m_next_local_addr` is expired
10:12 < amiti> sishir: yes
10:12 -!- oldgoat5 [2f9a575b@47.154.87.91] has joined #bitcoin-core-pr-reviews     
10:13 < genef> peer self-announces, addr gets fanned out by those nodes, then those nodes send off again to another send of nodes, repeat
10:13 < genef> set* of nodes
10:13 < amiti> ccdle12: yup! I believe you're referring to the periodic self announcements we initiate in SendMessages
10:13 < svav> Internode communication is dependent on Bitcoin protocol version
10:13 < amiti> that can be found here: https://github.com/bitcoin/bitcoin/blob/b14462083f82aeaa9a376978f210db5538db296f/src/net_processing.cpp#L4198-L4214
10:14 < svav> What bit of code determines node self announcement? How often does self announcement happen?
10:14 < amiti> genef: that relay pattern is true, but do you know what the "fan" factor is?
10:15 < amiti> svav: see the code I just linked :)
10:15 < glozow> not sure if someome already mentioned, we do one after connecting (outbound) to a node and receiving `VERSION` from them: https://github.com/bitcoin/bitcoin/blob/267b60f800cb298d6700ae54fdace595c0e80313/src/net_processing.cpp#L2435-L2458
10:15 < amiti> glozow: yes!
10:15 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-wxznujkcqniiokdf] has joined #bitcoin-core-pr-reviews     
10:16 < amiti> so, there are two code paths that initiate self announcements, which glozow & I have just linked
10:16 < amiti> 1. when we receive a `VERSION` message from a outbound not-block-relay-only peer, we will announce our address
10:16 < lightlike> svav: once a day on average, AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL = 24h in net_processing.cpp
10:16 < jnewbery> gleb had a PR to consolidate those two self-announcement mechanisms a bit: https://github.com/bitcoin/bitcoin/pull/19843 . The PR needs a bit of love and rebase now.
10:17 < amiti> 2. what lightlike just said, once a day on average per peer
10:17 < amiti> so, lets understand these two a bit better- why would we announce our own address after we've connected to a peer?
10:17 < glozow> is addr self-announcement on a poisson timer for privacy or for fanciness or?
10:18 -!- rjected [~weechat-h@natp-128-119-202-19.wireless.umass.edu] has joined #bitcoin-core-pr-reviews     
10:18 < b10c> it could be that we just joined the network and nobody knows us yet?
10:18 < sishir> to ensure that newly connected node becomes well known and better connected
10:19 < amiti> glozow: good question. let me ask you one in return- is privacy a concern when announcing your address?
10:19 < amiti> b10c, sishir: right, the behavior is asymmetric. if node A connects to node B, node B might not actually know node A's address
10:20 < amiti> so node A announces
10:20 < sishir> Does newly connected node sends addr & getaddr at the same time?
10:20 < amiti> after that announcement, what would we expect the propagation pattern to look like on the network ?
10:20 < amiti> (that announcement, or any announcement really)
10:21 < b10c> amiti: oh right, because with TCP you connect FROM a different port that you are listening on (and B doesn't know if you are listening at all).
10:21 < glozow> amiti: i can't really think of what you'd want to hide when self-announcing
10:22 < amiti> sishir: relevant code here https://github.com/bitcoin/bitcoin/blob/b14462083f82aeaa9a376978f210db5538db296f/src/net_processing.cpp#L2435-L2464, the logic paths are fired at the same time, but we send the getaddr right away, and queue up the addr for a bit later (when we process in SendMessages)
10:22 < sugarjig> Wouldn't node B only forward the addr message to 1 or 2 other nodes?
10:23 < b10c> amiti: B sends addr-of-A to other nodes
10:23 < amiti> b10c: exactly
10:23 < amiti> glozow: me neither!
10:23 < amiti> sugarjig: yup
10:24 < b10c> but if all B's would send it to their peers we'd flood, right? that's why we only send to 1 or 2 peers
10:24 < amiti> b10c: I don't understand this statement
10:25 < amiti> so, a node initiates a self announcement, and then when a peer receives the announcement it forwards the address to 1-2 peers
10:25 < amiti> see https://github.com/bitcoin/bitcoin/blob/b14462083f82aeaa9a376978f210db5538db296f/src/net_processing.cpp#L2680
10:25 < amiti> and "addr black holes" are when it doesn't actually forward it
10:26 < amiti> and this was already mentioned, some reasons for that could be: its a block-relay-only connection or its a light client
10:26 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]     
10:26 < genef> why don't block-only relays participate in addr forwarding?
10:26 < amiti> genef: good question, anyone know the answer?
10:26 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
10:27 < svav> When you create a node, how does it determine the first address of another node to connect to?
10:27 < genef> svav: DNS seeds
10:27 < amiti> so, the reason black holes could be an issue is if the addresses are not really getting propagated well around the network
10:27 < b10c> amiti: to rephrase RE propagation pattern: A self-announces to B, B only relays it to 1 or 2 peers as otherwise (compared to relay to e.g. all 50 peers) we'd flood the network with addr's, right?
10:27 < emzy> amiti: to prevent mapping the network.
10:28 < amiti> b10c: yup. correct
10:28 < ccdle12> couldn't an attacker determine a block-relay-only node by seeing that they don't forward addrs?
10:28 < sishir> genef why don't block-only relays participate in addr forwarding? +1
10:29 < glozow> because block-relay-only is block-relay-only
10:29 < genef> glozow: guess that makes sense, thought it just referred to they don't relay tx. really does mean "block"-only, lol
10:30 < lightlike> ccdle12: block-relay-only is not a node property, it's a connection property, currently a node has only 2 outgoing block-relay only connections. you could think of it as an extra stealthy network within the network.
10:30 < sishir> I though addr was just used for propagation? What do they do with the addr then
10:30 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has quit [Quit: Connection closed]     
10:30 < emzy> Via addr forwardings you can figure out which node is connected to which. Blocks-only prevents to find out about all connections of a node.
10:31 < amiti> some good questions and answers here :)
10:31 < sishir> lightlike ✅
10:31 < amiti> addr forwarding leaks some info about node topology, so block-relay-only connections wanted to avoid that entirely
10:31 < glozow> note difference between `-blocksonly` mode and a block-relay-only connection
10:32 < amiti> ok, so hopefully this is making sense so far
10:32 < amiti> lets move on to the next question:
10:32 < amiti> How does this PR propose to improve addr black holes? What are possible issues an approach like this could have? What does this approach not address?
10:32 < genef> maybe unrelated to this pr: could addr be forwarded using a Dandelion++-like protocol to obscure the origin-dest?
10:32 < emzy> glozow: good point. I was talking about block-relay-onl
10:32 < genef> ^background q
10:32 < glozow> genef: why do we want to obscure origin of addr?
10:33 < genef> this PR doesn't send to nodes that don't participate in addr propagation
10:33 < amiti> so let's clarify this: when relaying addrs, what relevant information is private vs public?
10:33 < genef> glozow: for the same reason block-only don't propagate, prevent addr mapping
10:33 < sishir> IP address
10:34 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
10:34 < amiti> so the contents of the addr message is my ip address / location
10:35 < amiti> I want this to be public information
10:35 < amiti> that's why I'm sending it out
10:35 < amiti> but, the pattern of how it gets sent out might reveal node topology, aka which peers I am connected to
10:35 < amiti> and that is something I want to keep private
10:36 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
10:36 < amiti> because if an attacker knows the network topology, it could make an attack like causing a partition tangibly easier
10:36 < amiti> does this make sense to people?
10:36 -!- jadi [~jadi@178.131.26.196] has quit [Read error: Connection reset by peer]     
10:37 < ivanacostarubio> https://developer.bitcoin.org/reference/p2p_networking.html#addr
10:37 < genef> yes     
10:37 < sugarjig> Yes!
10:37 < sishir> YES!
10:37 < ivanacostarubio> Yes. It makes sense
10:37 < amiti> awesome!
10:37 < amiti> cool, so lets go back to question 4:
10:37 < amiti> How does this PR propose to improve addr black holes? What are possible issues an approach like this could have? What does this approach not address?
10:37 < sishir> Postpones initialize of m_addr_known until peers sends an address related message
10:39 < amiti> sishir: yes! and then what do we do with that information? (of whether m_addr_known is initialized)
10:39 < lightlike> for outbound connections, nothing changes
10:39 < amiti> lightlike: good observation :)
10:40 < sishir> for inbound initialize filter when we get addr messages
10:40 < amiti> yup     
10:40 < b10c> does not change: one (or multiple) mallilicous peers could still be a addr-blackholes
10:41 < amiti> b10c: correct
10:41 < glozow> i also like that the PR makes nodes stop sending `SENDADDRV2` to block-relay-only peers
10:41 < amiti> so, we defer initializing `m_addr_known` for inbound peers until they send us a message that has to do with addrs
10:42 < amiti> how does this link back to not sending to black holes ?
10:42 < sugarjig> If we've never gotten an addr-related message from a peer, there's a good chance they could be a black hole
10:42 < genef> consider an inbound peer a black hole until they send addr info?
10:42 < amiti> yup, exactly!
10:43 < oldgoat5> "How does this PR propose to improve addr black holes?" - this pr appears to add a SetupAddressRelay flag, which can be set to true for full nodes, and false for light clients.  Currently some nodes are not likely to forward addresses (light clients), thus some announcements will be lost.  This pr wants nodes to declare whether they will forward
10:43 < oldgoat5> a relay or not, so the source nodes can skip light clients.
10:43 < oldgoat5> is this correct^?
10:43 < amiti> oldgoat5: mostly, but some clarifications: 1. there are other types of connections that won't forward addresses, eg. block-relay-only conn or potentially other software on the network
10:44 < amiti> 2. we use a heuristic to set the flag, and the heuristic is whether the conn is outbound, or inbound & send addr- related message
10:45 < lightlike> where did a typical light client that doesn't participate in addr relay but somehow managed to connect to us get our IP? From the DNS seeds?
10:45 < amiti> lightlike: great question, I don't know. does anybody else know ?
10:47 < ccdle12> maybe from websites like bitnodes? an edge case but they must have a db of node ips
10:47 < amiti> ok, we can keep this as an open question and keep moving :)
10:47 < amiti> lets discuss this part of the question: What are possible issues an approach like this could have?
10:48 < amiti> lightlike: you already brought up a potential problem at the bitcoin-dev meeting last week :)
10:48 < genef> could prematurely exlude nodes from addr relay
10:48 < b10c> I think BTCPayServer's NXExplorer does connect via P2P to your node and doesn't have anywhere to forward addr's
10:48 < jnewbery> lightlike: good question! Maybe it connected to some hard-coded peers, sent a getaddr to get a diversity of peers and then connected to some of them (?)
10:49 < amiti> genef: yes exactly
10:50 < svav> How many other nodes is a given node typically connected to?
10:50 < sugarjig> A node may not have any inbound peers that have announced an addr message, so could itself be a black hole
10:50 -!- petroleum [~petroleum@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews []     
10:50 < amiti> and that would suck, because this is the main technique for ongoing addr relay, so if a node doesn't hear about addrs, it would be more vulnerable to being eclipsed
10:50 < amiti> sugarjig: not quite, what about outbounds?
10:51 < genef> could it attempt to reseed from DNS peers again?
10:51 < amiti> svav: default values in bitcoin core are 8 outbound full relay, 2 block relay only peers, 125 total
10:51 < amiti> but there is also other software on the netwrok
10:51 < sugarjig> amiti: yep, if it has outbounds, then we're good
10:52 < amiti> sugarjig: oh interesting. I don't think bitcoin core can run on an inbound-only method. I'd have to check that you can't do something weird with startup flags though
10:53 < amiti> genef: yes, but unlikely. we also have other methods for getting addresses such as sending GETADDR when we connect to outbound peers
10:53 < genef> +1     
10:53 < amiti> so, I think the biggest concern with this proposal is that we don't accidentally exclude nodes from addr relay that are depending on it
10:54 < amiti> one piece of feedback that has been given to me is that I should communicate about this on the bitcoin-dev mailing list & research the expectations of other software on the network
10:55 < amiti> we can reasonably build confidence around behavior of bitcoin core nodes, but thats not sufficient
10:55 < amiti> so this kinda covers question #6 around how we could disrupt other software
10:55 < ccdle12> curious, what are the other pieces of software on the network that needs to be taken into account?
10:56 < amiti> we have 5 minutes left, which I don't think is enough to dig into question #5 or 7, so I'll open the floor to any remaining questions about addr relay
10:56 < glozow> i have a clarification question, if you're about to relay addrs and you have 0 candidates (e.g. no m_addr_known with any of your peers) for any of your non-source peers, do you also just not relay it?
10:56 < amiti> ccdle12: anything else running bitcoin protocol. there are some open source ones and there would be private ones too.
10:57 < svav> Why do you want to cut-off sending to blackhole addresses completely? Is that necessary?
10:57 < genef> do you think a DHT or using dandelion++ could help with obfuscating network topology?
10:57 < amiti> glozow: yes I believe so
10:57 < amiti> glozow: we could edit the tests to see, but pretty sure the `sort_func` in `RelayAddress` would just come up empty
10:57 < sishir> I gotta head out but thank you amiti! Learned a lot today
10:57 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Quit: Connection closed]     
10:57 < svav> Isn't it only a problem if a node sends messages out to ALL blackholes? So, can you just write the code to prevent this?
10:57 < amiti> genef: what is DHT?
10:57 < glozow> distributed hash table
10:58 < genef> distributed hash table ^
10:58 < amiti> genef: dandelion could definitely help obfuscate network topo through tx relay
10:58 < lightlike> this touches #7, but I'm really interested in it: have you considered the alternative approach treating addr messages to potential black holes as additional messages (but not stopping them) - e.g. relaying to one more peer if we suspect our peer is a black hole?
10:58 < amiti> oh, um, I guess depends on how it was used??
10:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
10:58 < amiti> lightlike: great question! and yes, I'm trying to think that through right now
10:59 < amiti> on one hand, that change can be considered "safer" because the observable addr propagation on the network shouldn't change
10:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
10:59 < svav> Yes, it's not a problem if you send a msg to a blackhold, but it is if you are sending to only blackholes, right?
11:00 < amiti> on the other hand, that behavior might be exploitable because you're relying on the peer to indicate to you whether or not they are a black hole, and maybe that could lead to them receiving more addrs than otherwise?
11:00 < amiti> ok! that's time! thanks for playing everyone :)
11:00 < amiti> #endmeeting
11:00 < glozow> i think dandelion is designed to protect against leaking transaction origin, idk if it helps with hiding network topology... i thought of those as distinct goals
11:00 < jnewbery> svav: the higher the proportion of black holes in the network as a whole, the worse addr propagation will be
11:00 < jnewbery> Thanks amiti. Great meeting!
11:00 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has quit [Ping timeout: 258 seconds]     
11:00 < glozow> thanks amizi!
11:01 < glozow> amiti*
11:01 < emzy> Thank you amiti! And thank you for all.
11:01 < lightlike> thanks amiti!
11:01 < gniemeyer> thanks yall
11:01 < b10c> Thanks amiti! This was super interesting and I learned a lot
11:01 < jnewbery> I wonder who'll host next week :thinking:
11:01 < amiti> glozow: agree they are distinct goals, but also think dandelion could probably help with both
11:01 < ccdle12> thanks amiti, interesting topic!
11:01 < svav> Thanks amiti and all
11:01 < glozow> amiti: yeah not conflicting, just distinct
11:01 < tkc_> thank you amiti
11:01 < glozow> I'M HOSTING NEXT WEEK
11:01 < glozow> it's an amiti PR too
11:01 < jnewbery> glozow: YAY! WHAT'S IT GOING TO BE ABOUT?
11:01 < glozow> R E B R O A D C A S T
11:02 < ivanacostarubio> Thank everyone and amiti! I learned a few things.
11:02 < jnewbery> ✨     
11:02 < glozow> https://github.com/bitcoin/bitcoin/pull/21061
11:02 < genef> thanks amiti and everyone
11:02 < jnewbery> come back same time same place next week for some rebroadcast knowledge!
11:02 < stortz> if that's the rebroadcast I'm thinking about, it's extremely useful
11:02 < b10c> uh 21061 is interesting!
11:03 -!- gniemeyer [~gniemeyer@c-71-198-251-246.hsd1.ca.comcast.net] has quit [Quit: leaving]     
11:03 < stortz> it is
11:03 -!- sugarjig [d81eb60a@216.30.182.10] has quit [Quit: Connection closed]     
11:03 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has joined #bitcoin-core-pr-reviews     
11:03 -!- genef [~gene@198.167.192.35] has quit [Quit: genef]     
11:04 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has left #bitcoin-core-pr-reviews []     
11:06 < jonatack> Meeting log is up at https://bitcoincore.reviews/21528#meeting-log 🍰
11:07 -!- tkc_ [a29af3ea@162.154.243.234] has quit [Ping timeout: 240 seconds]     
11:07 -!- tkc [~tkc_@162.154.243.234] has quit [Ping timeout: 252 seconds]     
11:08 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
11:08 < jnewbery> thanks jonatack!
11:09 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 240 seconds]     
11:10 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
11:19 -!- oldgoat5 [2f9a575b@47.154.87.91] has quit [Quit: Ping timeout (120 seconds)]     
11:31 -!- stortz [bb3fa18c@unaffiliated/stortz] has quit [Quit: Connection closed]     
11:38 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]     
11:41 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
11:44 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
11:57 -!- ivanacostarubio [~ivan@189.172.170.168] has quit [Ping timeout: 240 seconds]     
12:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
12:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
12:14 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:15 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
12:16 -!- jadi [~jadi@178.131.26.196] has quit [Read error: Connection reset by peer]     
12:47 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
12:47 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
12:54 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has quit [Ping timeout: 258 seconds]     
13:18 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
13:19 -!- jadi [~jadi@178.131.26.196] has quit [Read error: Connection reset by peer]     
13:33 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has quit [Quit: Connection closed]     
13:49 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
14:04 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
14:05 -!- jadi [~jadi@178.131.26.196] has quit [Ping timeout: 260 seconds]     
14:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]     
14:09 -!- lukedashjr is now known as luke-jr     
14:13 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
14:14 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
14:45 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
14:45 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
14:53 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has joined #bitcoin-core-pr-reviews     
15:06 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
15:11 -!- jadi [~jadi@178.131.26.196] has quit [Ping timeout: 260 seconds]     
15:21 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
15:22 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
15:23 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
15:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]     
15:25 -!- lukedashjr is now known as luke-jr     
15:25 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
15:30 -!- jadi [~jadi@178.131.26.196] has quit [Ping timeout: 240 seconds]     
15:57 -!- lightlike [~lightlike@p200300c7ef2d33009555da3eb4157696.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
16:18 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has quit [Ping timeout: 258 seconds]     
16:22 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has joined #bitcoin-core-pr-reviews     
16:49 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has quit [Ping timeout: 258 seconds]     
16:57 -!- ecola [~3cola@95.175.17.147] has quit [Ping timeout: 260 seconds]     
17:25 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has joined #bitcoin-core-pr-reviews     
18:22 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
18:22 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
18:28 -!- ivanacostarubio [~ivan@189.172.241.55] has joined #bitcoin-core-pr-reviews     
18:41 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews     
18:41 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Client Quit]     
18:46 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews     
18:51 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
18:53 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
18:54 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
19:13 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 268 seconds]     
19:26 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
19:31 -!- jadi [~jadi@178.131.26.196] has quit [Ping timeout: 240 seconds]     
19:43 -!- anna-news [~anew@2603-6011-4802-928a-1570-b0c6-2e04-78d7.res6.spectrum.com] has quit [Ping timeout: 258 seconds]     
20:20 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
20:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]     
20:48 -!- ivanacostarubio [~ivan@189.172.241.55] has quit [Ping timeout: 240 seconds]     
20:49 -!- ivanacostarubio [~ivan@189.172.237.148] has joined #bitcoin-core-pr-reviews     
21:15 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews     
21:27 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
21:28 -!- jadi [~jadi@178.131.26.196] has quit [Read error: Connection reset by peer]     
21:59 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
22:00 -!- jadi [~jadi@178.131.26.196] has quit [Remote host closed the connection]     
22:31 -!- jadi [~jadi@178.131.26.196] has joined #bitcoin-core-pr-reviews     
23:31 -!- ivanacostarubio [~ivan@189.172.237.148] has quit [Ping timeout: 265 seconds]     
23:40 -!- ivanacostarubio [~ivan@189.172.193.29] has joined #bitcoin-core-pr-reviews     
23:46 -!- jadi [~jadi@178.131.26.196] has quit [Ping timeout: 240 seconds]