Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle chain information in explicit form in invoices #104

Closed
wants to merge 7 commits into from

Conversation

dr-orlovsky
Copy link
Member

This is a breaking change since inside the invoice structure we make chain non-optional; plus we add new error cases and make set_chain return Result. Thus I am making this PR against v11 branch.

Closes #103

@dr-orlovsky dr-orlovsky added this to the v0.11.0 milestone Sep 18, 2023
Copy link
Member

@cryptoquick cryptoquick left a comment

Choose a reason for hiding this comment

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

ACK
Very comprehensive tests cases. Looks good.
I also agree, 0.11 is a good place to put this.

@fedsten
Copy link
Member

fedsten commented Sep 18, 2023

Any reason why it is non-optional instead of optional as discussed in #103?

@dr-orlovsky
Copy link
Member Author

dr-orlovsky commented Sep 18, 2023

@fedsten the parameter is optional as was discussed, thus the invoice string is backwards-compatible. However, for each given invoice we always know which network it belongs to (since we are defaulting to mainnet as discussed), thus we must have a non-optional field in the rust API.

@fedsten
Copy link
Member

fedsten commented Sep 18, 2023

Got it, for clarifying.

@dr-orlovsky
Copy link
Member Author

dr-orlovsky commented Sep 18, 2023

In other words, a wallet will always know and be sure to which network a given invoice belongs. If the invoice has conflicting network information (like an address network doesn't match the network provided in a parameter) it will error during the parse procedure. But each parsed invoice always knows which network it is valid for, and is guaranteed not to have network conflicts between address and parameter.

Copy link
Contributor

@zoedberg zoedberg left a comment

Choose a reason for hiding this comment

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

I'm trying to review the PR but executing tests I'm encountering some issues.
It seems that the LoadError is defined only when the fs feature is active but then used in other parts of code available without that feature. Moreover, if I run tests activating all features, I receive the following error:

error[E0599]: no method named `assume_checked` found for struct `bp::Address` in the current scope
   --> invoice/src/parse.rs:454:14
    |
452 |           let addr_bc = Address::from_str("bc1qpws79r3ea4yy2ujsahwrmy2gutdj8w5whnhket")
    |  _______________________-
453 | |             .unwrap()
454 | |             .assume_checked();
    | |             -^^^^^^^^^^^^^^ method not found in `Address`
    | |_____________|
    | 

error[E0599]: no method named `assume_checked` found for struct `bp::Address` in the current scope
   --> invoice/src/parse.rs:457:14
    |
455 |           let addr_tc = Address::from_str("mxVFsFW5N4mu1HPkxPttorvocvzeZ7KZyk")
    |  _______________________-
456 | |             .unwrap()
457 | |             .assume_checked();
    | |             -^^^^^^^^^^^^^^ method not found in `Address`
    | |_____________|
    | 

For more information about this error, try `rustc --explain E0599`.
error: could not compile `rgb-invoice` (lib test) due to 2 previous errors

@dr-orlovsky
Copy link
Member Author

dr-orlovsky commented Sep 20, 2023

@zoedberg wait, we do not have CI set up for this repo? Oh, I'll fix it.

I did this PR initially against v0.10 branch which is using rust-bitcoin v0.30. Then I understood it was breaking, so I moved to v0.11, which doesn't depend on rust-bitcoin at all and has a different Address type (from bp-std) with a different API. Thus the issue. Will fix.

@dr-orlovsky
Copy link
Member Author

Closing in favor of solution from #118

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

4 participants