pull down to refresh
The services flags indicate which optional peer services a node offers which is different from whether nodes understand a protocol feature. I would expect that they continue to get used.
OTOH, if BIP 434 is adopted, the protocol version might not need to be bumped further after the bump for BIP 434.
So signalling if your node is a pruned node is something that is a service flag, while the things covered by BIP 434 might be more like does your node know how to support encrypted transport?
Ah, I was worried that my short lived I2P example was also bad. Thanks for sharing the other examples!
Yeah, that I2P example felt a bit off-base. Nodes self-announce their (network-respective) address for each network they support to each peer after establishing a connection, i.e., on clearnet, a node will announce its clearnet address to peers. Such peers may then forward the address when they get asked for a batch of addresses by another node. I don’t remember whether nodes only gossip addresses of the respective network on each network, or whether they generally gossip addresses from all addresses (probably the latter?), but a node that doesn’t use I2P wouldn’t announce an I2P address, so we’d never try to connect to it with I2P.
wondering: what happens to
servicesin theversionmessage long-term.