pull down to refresh

202 sats \ 5 replies \ @Murch 23 Jan \ parent \ on: BIP 434: Peer Feature Negotiation - ajtowns bitcoin

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.

write
preview
100 sats \ 4 replies \ @Scoresby OP 23 Jan

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?

reply
102 sats \ 3 replies \ @optimism 23 Jan
does your node know how to support encrypted transport

I think that's a bad example because of how that protocol initializes from the first byte, but I guess that feefilter and addrv2 would be good examples.

reply
121 sats \ 2 replies \ @Scoresby OP 23 Jan

Ah, I was worried that my short lived I2P example was also bad. Thanks for sharing the other examples!

reply
102 sats \ 1 reply \ @optimism 23 Jan

Because you mention it, yes, I'm quite sure that it is, because you either have a listening i2p interface or you don't, but I didn't feel like dwelling on it, haha.

reply
302 sats \ 0 replies \ @Murch 24 Jan

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.

reply