Expose Address::is_valid_for_network

[jurvis]

Describe the enhancement
rust-bitcoin treats all addresses with the tb prefix as testnet addresses:

When parsing, such addresses are always assumed to be testnet addresses (the same is true for bech32 signet addresses).

However, they may not necessarily be that since regtest and signet share the same prefix. Exposing is_valid_for_network in Address would be more useful for users.

Use case
Implementing a text box/QR scanner that parses a bitcoin address and shows an appropriate error if its network does not align with the user's wallet.

Additional context
NA

[reez]

I'll start working on this-

[jurvis]

@reez thanks, Matthew!

Would be amazing if we also could get that cherry picked into a patch release for 0.30

[reez]

I have a Draft PR up for this.

Just for the Draft PR I decided to be super exhaustive about the unit tests for clarity on what is_valid_for_network would return in each scenario.

[thunderbiscuit]

Awesome!

@jurvis I want to make sure I understand your requirements/workflow (because the API doesn't quite do what I thought it did at first glance).

Do you intend to use this to make sure that an address matches a given wallet's network? If that's the case I think this will work in some cases, but in some others will not. For example you might have a signet wallet, scan a testnet address from a testnet faucet, then call the .is_valid_for_network(Network::Signet) method on this address and it would return true even though the address is actually testnet, and would therefore fail at runtime.

Let us know if this does exactly what you need, and if you can expand on how exactly you intend to use it that would be helpful.

As for the patch release, I think we'll be happy to release a patch for your team if this is something you need!

[jurvis]

For example you might have a signet wallet, scan a testnet address from a testnet faucet, then call the .is_valid_for_network(Network::Signet) method on this address and it would return true even though the address is actually testnet, and would therefore fail at runtime.

Yup, that seems fine to me. To my knowledge, that's the best we can do? We probably should also document the different expectations between using this API versus network() as well, since it will always return Testnet even when you pass it a Signet address.