Skip to content

Implement possible_networks function for Address#618

Merged
dr-orlovsky merged 1 commit intorust-bitcoin:masterfrom
elsirion:possible_networks
Aug 9, 2021
Merged

Implement possible_networks function for Address#618
dr-orlovsky merged 1 commit intorust-bitcoin:masterfrom
elsirion:possible_networks

Conversation

@elsirion
Copy link
Copy Markdown
Contributor

Parsed legacy addresses do not always have one network. The problem is that testnet, regtest and signet use the same prefix instead of multiple different ones. When parsing such addresses are always assumed to be testnet addresses. But if one wants to check against if the address belongs to the right network a simple comparison is not enough anymore.

@elsirion elsirion force-pushed the possible_networks branch from 647422a to 742cd8a Compare June 14, 2021 18:29
@dpc
Copy link
Copy Markdown
Contributor

dpc commented Jun 14, 2021

Does it make sense to have a

fn is_address_valid_for_network(addr: &Address, network: &Network) -> bool;

In many situations the caller will already know what network it needs, and just wants to do the "ok or not" check.

@elsirion elsirion force-pushed the possible_networks branch from 742cd8a to 37754f3 Compare June 14, 2021 20:00
Copy link
Copy Markdown
Collaborator

@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK, but the implementation ignores the fact that an address may be created using explicit network data and not parsed. Thus there might be an address with self.network set to Network::signet and this case would not be handled by the proposed implementation

@elsirion
Copy link
Copy Markdown
Contributor Author

If I understand you correctly you'd e.g. want a constructed regtest address to be compatible with testnet? I wonder what an elegant solution would look like. Essentially we are creating a compatibility matrix here.

@elsirion elsirion force-pushed the possible_networks branch from 37754f3 to 382df19 Compare June 15, 2021 09:24
@elsirion
Copy link
Copy Markdown
Contributor Author

I hope I implemented what you meant.

@sgeisler
Copy link
Copy Markdown
Contributor

I wonder how this function could be tested such that future expansions of the networks enum will lead to failure. Otherwise this function would fail silently by returning false even for addresses of the same network if it's not added to an equivalence class. Maybe we should add a function to Network that returns an exhaustive list, should be easy with the macro in place already.

Copy link
Copy Markdown
Collaborator

@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this might cause problems with Network enum extensions. What I propose here is to do the following:

match (self.network, network) {
    (a, b) if a == b => true,
    (Network::Bitcoin, _) | (_, Network::Bitcoin) => false,
    (Network::Testnet, _) | (Network::Regtest, _) | (Network::Signet, _) => true
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I think we do not need to introduce this constants since these values can be embedded right into match patterns below.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator

We also really need test vectors here covering all cases

Copy link
Copy Markdown
Collaborator

@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for updating the code and well-designed test case; there one thing though which I personally unsure (pls see my comment)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if I'm wrong, but we need to test different segwit versions here, aren't we?

This implies the question if Signet P2TR address is equivalent to Testnet P2TR address, which before the November is not deployed to the network...

Copy link
Copy Markdown
Contributor Author

@elsirion elsirion Jun 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: Just saw it's only the test, sure, although a bit silly imo.

feel free to ignore the original reply below

P2TR addresses are already valid (or they would be if there wasn't the bech32m problem) and would ideally follow the same conventions as other bech32 addresses. This means we can certainly not say that they aren't compatible, because that might limit interoperability (a wallet doesn't need to be aware of the destination address version's semantics with bech32 addresses and should "just work").

I also think that practically it will be easier to tighten the rules down the road should anything change.

A compromise would be to have three states: compatible, incompatible and unknown. That would allow the user to decide what to do.

@elsirion elsirion force-pushed the possible_networks branch from 7143971 to 94229ae Compare June 26, 2021 17:34
@elsirion
Copy link
Copy Markdown
Contributor Author

I added test cases for all witness versions.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator

Perfect, thank you!

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 94229ae, you don't have to fix the spell error.

}

/// Parsed addresses do not always have *one* network. The problem is that legacy testnet,
/// regtest and signet addresse use the same prefix instead of multiple different ones. When
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit (NOT MERGE BLOCKING)
/s/addresse/addresses

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume I'll not fix it to not invalidate reviews unless a major change request comes in.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator

dr-orlovsky commented Aug 9, 2021

Seems to be non-breaking PR with a single commit meeting all the requirements, just introducing a single function + more tests, so will dare to merge it

@dr-orlovsky dr-orlovsky merged commit 8ae030b into rust-bitcoin:master Aug 9, 2021
@dr-orlovsky dr-orlovsky added this to the 0.28.0 milestone Sep 25, 2021
@elsirion elsirion deleted the possible_networks branch February 11, 2023 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants