< vasild>
Is my understanding correct that we don't send addresses or transactions via block-only connections, but the peer on the other end of a block-only connection may still send us addresses or transactions? Is the peer even aware that it is block-only connection for us?
< lightlike>
vasild: We signal in the version message whether we want txRelay. I believe if a peer still send a tx or a tx inv in violation, they will be disconnected.
< lightlike>
Addrs will be ignored on block-relay-only connections but processed in -blocksonly mode (our peer cannot easily distinguish between these two), no disconnections there
< vasild>
hmm
< provoostenator>
I'd like to nominate #21934 for v22 because monitoring signalling in the next few months is quite useful.
<@gribble>
https://github.com/bitcoin/bitcoin/issues/21934 | RPC/blockchain: getblockchaininfo: Include versionbits signalling details during LOCKED_IN by luke-jr · Pull Request #21934 · bitcoin/bitcoin · GitHub
< laanwj>
vasild: yes i remember during the bip155 discussion there were some ideas to also incorporate 'do not send me addresses at all', but this was not done, i had to think of this with #22245
< vasild>
I am composing a rely to that PR with a link to that discussion...
< laanwj>
i don't think there is any way to signal to not want addresses so i'm not sure why addrv1/addrv2 matters
< laanwj>
not even from a bandwidth perspective: addrv2 might be *more* efficient to ignore
< laanwj>
e.g. ipv4 addresses (the most common) take fewer bytes
< jnewbery_>
laanwj: bandwidth is irrelevant. Nodes only send one addr message per 24 hours on average, and the max size is 1000 entries.
< laanwj>
right, it's the only possible concern i could think of anyhow
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22258: build: Disable deprecated-copy warning only when external warnings are enabled (master...2106-buildEnableWarnDeprecatedCopy) https://github.com/bitcoin/bitcoin/pull/22258
< jonatack>
the disable_tx discussions left me with the recollection that, rather than encapsulating complex state in connection types, we might be heading back to separate flags, e.g. disable tx, disable addr, etc.
< jonatack>
in the BIP155 discussions nearly a year ago, it was decided that disable addr was a separate concern from BIP155-capable, thus the current implementation
< jonatack>
those do seem like separate concerns / flags / BIPs etc
< vasild>
I never thought that "send me addrv2 instead of addr" may imply a preference to receive address messages (them being addrv2 or addr). My Enflisch is nae good.
< vasild>
jnewbery: ^
< jonatack>
vasild: just saw your review, agree
< jonatack>
(communication may have been a bit siloed on some topics, by habit / time zones / affinities etc)
< jonatack>
(reviewers of certain areas, and so on)
< laanwj>
vasild: me neither
< laanwj>
it wasn't my intent at least when writing it
< laanwj>
i really meant it as a specification of what is supported by the client (remember that initially i started with a protocol version number bump only, the message came later because that turned out to be the preferred signaling mechanism now)
< laanwj>
then the protocol version bump was added again because other implementations
< laanwj>
i never once considered it a preference with regard to receiving messages
< jnewbery>
vasild: why would I say "send me red apples instead of green apples" when I don't eat apples at all?
< jnewbery>
And if you send me an apple I'm going to put it straight in the trash
< laanwj>
that's just how the BIP was intended, it could just as well have been a service flag which is always sent
< laanwj>
as I said above, the fact that it's an extra message is an implementation detail
< jnewbery>
I'm very confused about why it's controversial to not send a message that has zero impact on our own processing
< laanwj>
there is no message to say "I don't want to receive address messages"
< vasild>
jnewbery: bad English, sorry
< jnewbery>
Why would I send a message to say "please send me addrv2 messages that I'll throw away instead of sending addr messages that I'll throw away"?
< laanwj>
because you will still receive v1 messages that you'll throw away
< laanwj>
it doesn't matter
< jnewbery>
so why send the message?
< laanwj>
but anyhow, ok, I don't understand why this is such a topic of contention teither
< laanwj>
never minds
< vasild>
natural language is vague, we should be talking with "if ()", ">" and "==" ;-)
< laanwj>
I did think a signal whether a peer is interested in address messages or not is orthogonal to what messages it supports or not, there was discussion to include this in BIP155 at some point but it wasnm't
< laanwj>
I do think such a signal is useful fwiw
< laanwj>
but I don't see how sendaddrv2 is helpful here
< jnewbery>
laanwj: but that's not what the PR does?
< jnewbery>
it doesn't prevent message relay
< laanwj>
I understand that
< jonatack>
there was a real discussion about it, no need to rehash a year later
< laanwj>
if it prevented message relay it'd be a much more useful change
< jnewbery>
laanwj: I'm confused. I thought that's what you're arguing against
< laanwj>
"I don't want address messages from block-only peers" fine
< laanwj>
no, I'm arguing against misinterpreting BIP155
< jnewbery>
but this isn't misinterpreting BIP155. BIP155 is totally irrelevant for links that don't support address relay
< laanwj>
but was you say this doesnt disable address relay
< laanwj>
address relay isn't disabled for the connection
< jnewbery>
laanwj: what happens when I open an outbound blocks-only connection and receive an addr message on that connection?
< vasild>
jnewbery: there is more to this - a peer may maintain a useful database of addresses but not participate in address relay, so he is interested in receiving address gossip but is a black hole wrt further address propagation
< vasild>
jnewbery: it is ignored
< jnewbery>
if it's ignored then how can "he's interested in receiving address gossip" be true?
< vasild>
the peer I mentioned is not blocks-only
< vasild>
may be a light client
< jnewbery>
so how's that relevant to PR 22245?
< vasild>
he is interested in receiving address gossip in order to maintain his own addresses databas
< jnewbery>
22245 is only for blocks-relay-only connections
< jnewbery>
talking about light clients seems completely irrelevant to the PR
< vasild>
22245 implies we put a new semantic to sendaddrv2: "However, if we move forward with the approached proposed in that PR"
< jnewbery>
22245 doesn't change the semantics of sendaddrv2 at all. It simply doesn't send the message when it's irrelevant
< lightlike>
jnewbery: i think we expect to receive addr messages on block-relay-only connections currently, because out peer doesn't know from the version messages whether this is a block-relay-only link or a regular connection in -blocksonly mode (for which we want addrs)
< jnewbery>
lightlike: the peer doesn't even know that the connection is not a full-relay-connection
< jnewbery>
> !A and !B (it follows that if you send me a reply to my getaddr it should be in the old addr format because I don't support the new addrv2)
< vasild>
jnewbery: #21528 changes the semantic of sendaddrv2 and #22245 only makes sense if #21528 is accepted
< jnewbery>
that doesn't make sense here. If we receive a reply to a getaddr on an outbound block-relay-only connection, then we drop it.
< jnewbery>
22245 seems like a good change independently from 21528 to me
< lightlike>
vasild: I don't agree with that. 22245 should make just as much sense using just ADDR,ADDRV2 and GETADDR as signs that the node is interested in addr relay. SENDADDRV2 doesn't seem necessary to me
< jonatack>
jnewbery: it indeed would widen the meaning of sendaddrv2, and irreversibly
< jnewbery>
jonatack: I still don't understand why you keep saying that
< jnewbery>
if I don't do anything with addrs received on a link, then asking my peer to send those addrs (which I'm going to ignore) in a certain format, is neither useful, nor irreversible
< jnewbery>
can you help me understand why you think this change is irreverible?
< jnewbery>
lightlike: I think you meant "21528 should make just as much sense using just addr, addrv2 and getaddr" (and I agree)
< vasild>
If we look at 22245 in isolation (as if 21528 does not exist) then it is pointless change. Why make it? The peer is then going to send us addr which we ignore (instead of addrv2 which we ignore). Also we would be lying that we don't support addrv2 when we actually do. Just does not feel right.
< vasild>
But I think the bigger argument here is 22245+21528 and changing the semantic of sendaddrv2 in order to tweak address relay and attempt to fix the black holes problem. But would even that fix it? Some scenarios where it will not: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-862312851
< jnewbery>
`sendaddrv2` only has meaning within a single connection. It means "I prefer to receive addrv2 messages on this connection". It implies nothing about the implementation of the node (as it shouldn't). Not sending a sendaddrv2 message is not "lying that we don't support addrv2", but simply not expressing a preference for a certain format *on that connection*.
< jnewbery>
If this was a service bit, which is gossiped beyond a single connection, then I'd agree with you, but all p2p messages only have semantic meaning within the connection that they exist in
< laanwj>
the point is that there is no way to "not express a preference"
< laanwj>
either the preference is v1 (not message) or v2 (send a message)
< jnewbery>
the way to "not express a preference" is to not "express a preference"
< laanwj>
there could have been a third option in BIP155 but there wasn't
< vasild>
It means "I prefer to receive addrv2 messages on this connection" -- this is your interpretation.
< laanwj>
no, it's not
< laanwj>
that would mean that a peer that doesn't send the message doesn't fcare what it receives
< laanwj>
whereas it means that it wants to receive v1
< laanwj>
there is no "I don't want to receive addr" signal, nor is there "I don't care"
< laanwj>
maybe there should be! but there isn't
< jnewbery>
vasild: the BIP says "Sending such a message indicates that a node can understand and *prefers to receive addrv2 messages*" - yes, my interpretation of this is that it prefers to receive addrv2 messages
< vasild>
INSTEAD
< laanwj>
signaling the new protocol version then *deciding* not to send the message means your node wants to receive v1
< jnewbery>
laanwj: that's not how p2p versions work
< laanwj>
well it is how I intended BIP155, I don't really agree with the new interpretation
< jnewbery>
since they're serial, if a later p2p version adds some other feature, it doesn't automatically mean that anyone using that feature *must* implement addrv2
< vasild>
jnewbery: you skipped the trailing "instead..." which is important.
< jnewbery>
I didn't think I was misrepresenting it. Here you go: "Sending such a message indicates that a node can understand and prefers to receive addrv2 messages instead of addr messages. I.e. "Send me addrv2"."
< laanwj>
jnewbery: which is why there is the option not to send the message: it implies you want to keep reciving v1
< laanwj>
there are two states, not three or four
< vasild>
anyway, if sendaddrv2 signalled preference to receive unrequested address messages, then bitcoin core-pre-bip155 do not want to receive unrequested address messages?
< jnewbery>
laanwj: A BIP cannot specify that not sending something implies some meaning. BIPs are opt-in. I can't say in my BIP "not sending this message implies thing".
< vasild>
because they do not send sendaddrv2
< laanwj>
jnewbery: in this case not sending the message is the old behavior of 'send me v1'
< jnewbery>
vasild: huh? I think you really misunderstand 22245 and 21528.
< laanwj>
there's the old behavior anhd the new behavior
< jnewbery>
a pre-bip155 bitcoin core node will send a getaddr, which implies that it wants to receive addresses
< laanwj>
but I honestly don't understand why this is such a hotbed issue before the v22.0 feature freeze
< jnewbery>
it will also send addr messages, which implies that it's taking part in address relay
< laanwj>
there would have been tons of time to discuss this with less time pressure
< vasild>
jnewbery: would you say that if a node sends getaddr it follows that it wants to also receive unrequested address messages, outside of the response of that getaddr? And from that would you say it follows that this node participates in address relay (gossips to other nodes)?
< laanwj>
I wasn't aware either that sending "getaddr" changed the connection status in that regard
< vasild>
laanwj: my understanding is that 21528 intends to achieve that (sending getaddr changed the connection status...)
< laanwj>
but if you can regard "getaddr" as a signaling message to receive unrequested address messages, and a peer never sending it effectively signals it doesn't ever want to see address messages, then you're right, there are three states
< jnewbery>
laanwj: that's what #21528 is proposing. If a peer sends us `addr` OR `addrv2` OR `getaddr` OR `sendaddrv2`, then we should consider it a peer for address gossiping. I think it makes sense to review that PR.
< jnewbery>
I don't think it's aggressive to expect people to read PR descriptions
< laanwj>
I'm not aware of every single PR description
< laanwj>
I just cannot keep up wit hthat
< jnewbery>
laanwj: this has been discussed in many venues already. It's been raised on the mailing list, discussed in bitcoin core irc and p2p irc meetings, amiti has even done a survey of every other common node implementation to make sure it doesn't break them: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430
< vasild>
hmm, actually laanwj is right that 21528 is not related to just bitcoin core - it changes the semantics of getaddr, addr, addrv2 and sendaddrv2. I guess that warrants a BIP.
< laanwj>
jnewbery: that's good
< laanwj>
vasild: yes, likely instead of your proposed BIP155 change
< laanwj>
(as it goes the other way)
< laanwj>
which is fine, if you're trying to change something, just be transparent about it, a while before you were still claiming this doesn't make any irreversible change to behavior
< jnewbery>
laanwj: are you saying that I'm not being transparent?
< jnewbery>
22245 makes no irreversible changes to behavior
< laanwj>
it came across to me as "this was always the case"
< jnewbery>
all of this has been discussed many times on github, irc, mailing list. How could it be more transparent?
< laanwj>
maybe it's just the nthat taking that part out of the parent PR separetely was unclear to people
< vasild>
Today is the first time I hear about it, sorry.
< laanwj>
yeah
< vasild>
it == 21528+22245
< jnewbery>
laanwj: I suggested to amiti that 22245 be separated from 21528, so I apologize if that was confusing for people and take full responsibility
< jnewbery>
it seems to me like a good change independent from 21528
< vasild>
IMO 21528+22245 is a protocol change.
< jnewbery>
vasild: it's not a protocol change
< vasild>
the semantic of e.g. getaddr is changed (extended)
< laanwj>
by itself (without other context) it seemed like a misinterpretation of BIP155 as i had intended it
< laanwj>
seeing it as part of a large change is completely different
< jnewbery>
laanwj: the first sentence in the PR description links to the 21528. I don't understand how it's not transparent
< laanwj>
so okay, you *are* trying to amke a protocol change
< jnewbery>
what?
< jnewbery>
can you please stop the insinuations that I'm trying to do something underhand?
< laanwj>
what, I dont' mean you are trying to make a sneaky protocol change
< laanwj>
I haven't said anything about being underhand
< laanwj>
I just didn't understand
< jnewbery>
you said that I'm not being transparent
< jamesob>
seems clear that there's enough unresolved discussion here that merging these changes in before the feature freeze isn't the way to go. and that conversations like these would be much more amicable IRL!
< jnewbery>
laanwj: I'd suggest re-reading the irc meeting logs from when this was discussed, both in the main Bitcoin Core meeting, and in the p2p meeting. You commented in the first meeting in March, so you were aware that this was a proposal.
< jnewbery>
It's very frustrating to see someone put in months of work on something, raise it in both irc meetings, share it on the mailing list, do a huge amount of work to verify compatibility with other nodes, and then see people show up and leave opinionated comments without reading and understanding the full context.
< jamesob>
jnewbery: no doubt man, but to some extent that's just the nature of the beast re: the project's decentralized development process. I haven't seen mention of an irreversible widening of the protocol's semantics earlier than jonatack's comment 8 hours ago, and I think once something like that is raised it deserves to be fleshed out over some time
< jnewbery>
I'm still waiting for jonatack to explain why this is an "irreversible change"
< michaelfolkson>
It is regrettable but if laanwj vasild jonatack are all uncomfortable with it getting in before feature freeze then we should probably move on. Lots of other things to discuss for feature freeze
< _aj_>
jnewbery: <jnewbery> you said that I'm not being transparent // -!- laanwj [~laanwj@user/laanwj] has quit
< ariard>
notwithstanding making the discussion far less heated for the sake of everyone, i agree that's a sender-only change and i don't see how it would restrain a future bip155 client to probe addrv2 support with its selected v22.0+ peers
< ariard>
that's the bip is unclear and not interest in addr format doesn't signal lack of interest in addr-relay sounds a different issue there, imho
< bitcoin-git>
[bitcoin] Sjors opened pull request #22260: Make bech32m the default, except where needed. Update GUI checkbox. (master...2021/06/bech32_gui) https://github.com/bitcoin/bitcoin/pull/22260
< bitcoin-git>
[bitcoin] jnewbery opened pull request #22261: [p2p/mempool] Two small fixes to node broadcast logic (master...2021-06-broadcast-fixes) https://github.com/bitcoin/bitcoin/pull/22261
< WS_black22>
i got my old wallet.dat i need to imported to the new bitcoin core, how can i do this? i dont see the replasment of wallet.dat,
< amiti>
hey all, looks like I missed lots of convo about my work to mitigate-addr-blackholes. I've caught up on the conversation here & the PRs and want to share two main thoughts:
< amiti>
1. My biggest question is why are these approach concerns only being raised now?
< amiti>
To review the context of this work: I opened #21528 almost 3 months ago, and soon after brought it up at the weekly bitcoin-core-dev meeting to seek approach feedback. A lot of the concerns that are now being voiced (should there be a separate flag, could we do redundant relay for blackholes rather than selective, what are the implications for other clients) have already been discussed in relation to these changes. My
< amiti>
understanding was the biggest concern was about compatibility for other clients, so I wrote to the mailing list and researched / opened issues in every other bitcoin client I could find. I’ve additionally brought up these changes at a P2P meeting in early April and then again this week. I understand that time zones are hard and that not everyone can attend the meetings, but I’d hope the logs would be read and concerns to
< amiti>
be raised in the week that follows.
< amiti>
It’s pretty disheartening to spend a long time trying to clear the conceptual obstacles for this work, to then loop back and rehash the same conversations. So this brings me back to the question of why are these approach concerns only being raised now? I’m genuinely perplexed because between the PR, irc meetings & the mailing list, I thought I was very vocal about these changes. If our only takeaway is how we avoid these
< amiti>
sort of drawn-out circular conversations, at least this will have been a constructive experience.
< amiti>
2. In regards to the path forward for #21528 & #22245, it seems like the concerns are all focusing specifically on SENDADDRV2 and the wording of that specific bip. #21528 can proceed without using SENDADDRV2 (aka without #22245), but imo it would make more sense to treat it consistently with ADDR, GETADDR and ADDRV2 messages. While I do think the change is a standalone improvement, the end goal is to support more
< amiti>
block-relay-only connections (and address the concerns I had about the disabletx proposal). In the end, if the only remaining concern is really around SENDADDRV2, I will remove that piece. But I would prefer to keep it logically consistent with the rest of the proposed changes.
< amiti>
Its clear that network-wide addr relay is something filled with murky assumptions, and divergent expectations, but I’m hoping to find a way forward for these goals.
< amiti>
laanwj, vasild, jonatack: I'm interested in hearing your opinions on these two points. thanks in advance!
< amiti>
also sorry for all the gribbles =P
< achow101>
amiti: from a cursory review of all of the discussion on this topic that I could find, the issue is with the specific implementation of #22245, which, afaict, is not discussed anywhere except when that PR was opened. I get that it was broken out of #21528 but I don't see where that specific change is discussed.
< sipa>
i don't think the sendaddrv2 aspect of the discussion is relevant
< sipa>
(only to the extent that it drew attention to the fact that 21528 is changing behavior for a number of messages including sendaddrv2)
< achow101>
it seems to me that the concerns are with 22245 itself, not with the concept of avoiding addr blackholes
< sipa>
22245 is utterly harmless on itself
< sipa>
sending sendaddrv2 or not makes no difference, as the received addr messages are just ignored
< achow101>
sipa: but with 21528 it gains an additional meaning?
< sipa>
achow101: not in my opinion, but yes, i think that is the disagreement
< amiti>
this is kinda what I'm trying to clarify- are the concerns solely about the sendaddrv2 message, or are they about the general approach
< amiti>
but yeah, I conceptually agree with what sipa just voiced
< sipa>
amiti: actually, question i have: if 21528 would exclude sendaddrv2 (just not use it as a trigger when received), what would happen for relay to block only peers?
< amiti>
so, if 21528 only used ADDR, ADDRV2, GETADDR to indicate "interest in addr relay", then bitcoin core nodes wouldn't initiate any of those to outbound block-relay-only connections. but nodes who have started up in blocks-only mode would initiate a GETADDR to their outbound peers.
< amiti>
and participate in other ADDR relay
< sipa>
amiti: so what difference would that make?
< amiti>
sipa: right, so I don't quite get why sendaddrv2 would / should be treated differently, and have a preference for logical consistency across p2p messages. BUT if the concern is *exclusively* about sendaddrv2 messages & not matching the intent when writing the bip, I can just leave it out and continue forward.
< sipa>
amiti: yeah, i'm just trying to understand the tradeoffs
< sipa>
not suggesting anything specifically
< amiti>
gotcha, imo the main tradeoff of using sendaddrv2 or not is just "logical consistency" of treating it the same as other address messages. no observable functional difference based on current clients
< amiti>
also in the research of other clients, I wasn't specifically looking, but didn't see much support for sendaddrv2, so suspect it would have minimal impact there too.
< sipa>
got it, thanks
< amiti>
:)
< achow101>
is 22245 required for 21528 or just "makes things consistent"? If the latter, I would suggest just dropping/skipping it for now.
< achow101>
it seems to me it doesn't really get in the way
< sipa>
i think i'm leaning in that direction too; trying to write my thoughts a bit more structured on the PR
< amiti>
yup, not my preference but totally viable. if we're going that route, I'd like to better understand the reasoning around treating sendaddrv2 differently, and then can update 21528 & close 22245.
< hiii>
Hi, is this the main bitcoin dev channel?
< michaelfolkson>
hiii: "Bitcoin Core development discussion and commit log"
< hiii>
thanks
< hiii>
where can I ask about summerofbitcoin? sorry if this is off topic
< michaelfolkson>
hiii: #bitcoin
< hiii>
michaelfolkson: thank you so much, i asked here since it was a btc core developer program, apologies