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

Output Descriptors #1363

Merged
merged 10 commits into from Jan 8, 2021
Merged

Output Descriptors #1363

merged 10 commits into from Jan 8, 2021

Conversation

prusnak
Copy link
Member

@prusnak prusnak commented Nov 21, 2020

Fixes #1362

In order to fully support Output Descriptors we need to change things on couple of places:

  • common
    • add GetPublicKey.ignore_xpub_magic and PublicKey.root_fingerprint fields
  • python
    • add trezorctl btc get-descriptor command
    • add tests for trezorctl btc get-descriptor command`
    • update get-descriptor test to include correct root_fingerprint
  • legacy
    • implement ignore_xpub_magic
    • implement root_fingerprint
    • show XPUB instead of Pubkey in GetPublicKey screen
    • add ignore_xpub_magic tests
    • add root_fingerprint tests
  • core
    • implement ignore_xpub_magic
    • implement root_fingerprint
    • show XPUB instead of Pubkey in GetPublicKey screen
    • add ignore_xpub_magic tests
    • add root_fingerprint tests

@prusnak prusnak marked this pull request as draft November 21, 2020 11:29
@prusnak prusnak added this to the 2021-01 milestone Nov 21, 2020
@prusnak prusnak force-pushed the descriptors branch 2 times, most recently from bf0ed99 to 9af06e7 Compare November 21, 2020 21:55
@matejcik
Copy link
Contributor

what is the reason for ignore_xpub_magic? wouldn't it be better for the client to strip/recalculate that?

@prusnak
Copy link
Member Author

prusnak commented Nov 30, 2020

what is the reason for ignore_xpub_magic? wouldn't it be better for the client to strip/recalculate that?

We need to show the same xpub on the display, without that flag the trezor shows ypub... or zpub... and the descriptor shows xpub...

@matejcik
Copy link
Contributor

We need to show the same xpub on the display

I'm wondering whether there should be a GetDescriptor call then. Comparing display XPUB and host-side full descriptor is weird.

OTOH I can see uses for the xpub display other than the descriptor, so 🤷‍♀️

)

fingerprint = pub.root_fingerprint if pub.root_fingerprint is not None else 0
external = "[{:08x}{}]{}/0/*".format(fingerprint, path[1:], pub.xpub)
Copy link
Contributor

Choose a reason for hiding this comment

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

please use f-strings

Copy link
Member Author

Choose a reason for hiding this comment

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

Addressed in 15c3753

external = "[{:08x}{}]{}/0/*".format(fingerprint, path[1:], pub.xpub)
internal = "[{:08x}{}]{}/1/*".format(fingerprint, path[1:], pub.xpub)

return (fmt.format(external), fmt.format(internal))
Copy link
Contributor

Choose a reason for hiding this comment

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

please don't use outer parens

Copy link
Member Author

Choose a reason for hiding this comment

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

Addressed in 15c3753

)
)


def get_descriptor(
Copy link
Contributor

Choose a reason for hiding this comment

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

this function should move to trezorlib.cli.btc as it's too high-level for this file

it should also probably accept address_n, and the get-descriptor command should also accept -n/--address, plus possibly -a/--account as a convenience shortcut

Copy link
Member Author

@prusnak prusnak Nov 30, 2020

Choose a reason for hiding this comment

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

I prefer this won't accept address_n - I don't see a good reason why it should.

Will move this to trezorlib.cli.btc

Copy link
Member Author

@prusnak prusnak Nov 30, 2020

Choose a reason for hiding this comment

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

If I moved this to trezorlib.cli.btc, where should I move the test from 9af06e7?

I really want to have this feature properly covered by tests.

Copy link
Contributor

Choose a reason for hiding this comment

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

well the reason to accept address_n is to allow use by coins other than Bitcoin, but i don't care that much so eh

re tests, we can keep them where they are, importing from trezorlib.cli namespace is not discouraged or anything

i'm thinking that the bulk of the functionality should be tested in python/tests presumably by mocking out the btc.get_public_node call?
(i don't think it is super important though)

Copy link
Member Author

Choose a reason for hiding this comment

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

Function moved to cli.btc in 15c3753

Tests moved in ec4d3c3

else:
raise exceptions.TrezorException("Unsupported account type")

# TODO: correctly lookup SLIP44 for coin provided
Copy link
Contributor

Choose a reason for hiding this comment

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

In context of accepting address_n, it's not important that we don't have the full SLIP44 lookup here. (fwiw we don't bundle the data for this anymore)

Copy link
Member Author

Choose a reason for hiding this comment

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

Let's drop the SLIP44 lookup completely and accept only Bitcoin/Testnet in the func

@matejcik
Copy link
Contributor

left some comments on python part

LGTM on core side

did not review legacy, i might look at it later if nobody else does

@tsusanka tsusanka removed their request for review December 1, 2020 07:58
@matejcik
Copy link
Contributor

matejcik commented Dec 1, 2020

reviewed legacy as well, looks good

@prusnak
Copy link
Member Author

prusnak commented Dec 1, 2020

I updated the tests to test the cli module in ec4d3c3, but now they fail with:

E           TypeError: 'TrezorClientDebugLink' object is not iterable

Can you please advise?

@prusnak
Copy link
Member Author

prusnak commented Dec 2, 2020

I updated the tests to test the cli module in ec4d3c3, but now they fail with:

Fixed in 1bad419

@tsusanka tsusanka modified the milestones: 2021-01, 2021-02 Dec 29, 2020
@prusnak prusnak force-pushed the descriptors branch 3 times, most recently from 92f4dd1 to f5b8161 Compare January 5, 2021 14:46
@prusnak prusnak marked this pull request as ready for review January 5, 2021 14:47
@prusnak
Copy link
Member Author

prusnak commented Jan 5, 2021

This is now ready for review. One things I am unsure about:

There are two ways how to obtain the root fingerprint:

  1. hack the derive function to return not only a derived node, but also a root fingerprint
  2. derive a dummy node (e.g. m/0') and return a parent fingerprint stored in that node

I used method 1 in Legacy and method 2 in Core. My reasoning is that using method 2 in Core would introduce lots of code/typing changes, but I do agree that method 2 is quite a hack. We might consider using method 2 for Legacy as well.

Let me know what you think.

@prusnak prusnak requested a review from matejcik January 5, 2021 14:55
@andrewkozlik
Copy link
Contributor

There are two ways how to obtain the root fingerprint:

  1. hack the derive function to return not only a derived node, but also a root fingerprint
  2. derive a dummy node (e.g. m/0') and return a parent fingerprint stored in that node

I used method 1 in Legacy and method 2 in Core. My reasoning is that using method 2 in Core would introduce lots of code/typing changes, but I do agree that method 2 is quite a hack. We might consider using method 2 for Legacy as well.

Let me know what you think.

Method 2 is cleaner, but I don't have a problem with either of the two approaches. It's no big deal if this is implemented slightly differently in core and legacy, so I'd say it's OK as is.

@matejcik
Copy link
Contributor

matejcik commented Jan 8, 2021

There are two ways how to obtain the root fingerprint:

  1. hack the derive function to return not only a derived node, but also a root fingerprint
  2. derive a dummy node (e.g. m/0') and return a parent fingerprint stored in that node

I used method 1 in Legacy and method 2 in Core. My reasoning is that using method 2 in Core would introduce lots of code/typing changes, but I do agree that method 2 is quite a hack. We might consider using method 2 for Legacy as well.

I'm a little confused here, ISTM both core and legacy are using the same method?
Personally I'd think the cleanest solution would be a root_fingerprint() function in crypto, but that seems needless, the employed solution looks good enough

@prusnak
Copy link
Member Author

prusnak commented Jan 8, 2021

I'm a little confused here, ISTM both core and legacy are using the same method?

I reworked it to use the same method and force-pushed.

@prusnak
Copy link
Member Author

prusnak commented Jan 8, 2021

Can you please @andrewkozlik have one last look at reworked legacy change (that uses the same method as core, i.e. deriving m/0'): c76145a

Copy link
Contributor

@andrewkozlik andrewkozlik left a comment

Choose a reason for hiding this comment

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

utACK for the root_fingerprint derivation.
However, note that the UI test are failing.

@prusnak
Copy link
Member Author

prusnak commented Jan 8, 2021

Hm, about the tests: for some strange reason I'm getting different hashes each time I run pytest test_descriptors.py --ui=record. Can someone else have a look at it? Maybe @tsusanka has an idea?

@andrewkozlik
Copy link
Contributor

Hm, about the tests: for some strange reason I'm getting different hashes each time I run pytest test_descriptors.py --ui=record. Can someone else have a look at it? Maybe @tsusanka has an idea?

I suppose it could be the pulsating swipe arrow, but we have the same thing in test_msg_backup_device.py, so the UI tests should be accustomed to it.

@tsusanka
Copy link
Contributor

tsusanka commented Jan 8, 2021

I suppose it could be the pulsating swipe arrow, but we have the same thing in test_msg_backup_device.py, so the UI tests should be accustomed to it.

Yes, the pulsing should disabled as the tests are run against emulator with disabled animations. I'll double check though.

@prusnak
Copy link
Member Author

prusnak commented Jan 8, 2021

I confirm I have reproducible hashes using TREZOR_DISABLE_ANIMATION=1 when running the tests.

Let's wait for the CI.

@tsusanka
Copy link
Contributor

tsusanka commented Jan 8, 2021

Yes and it is in the Makefile so we should be all good.

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.

trezorctl trezorctl btc get-descriptor command
4 participants