Legacy firmware support for Unchained paths

[Shadouts]

This change supports new Unchained paths for p2wsh addresses on legacy devices.

[onvej-sl]

I found two differences to how this is implemented in core:

• This pull request completely disables using the paths m/45'/coin_type'/account'/[0-1000000]/change/address_index and m/45'/coin_type/account/[0-1000000]/change/address_index for singlesig.
• This pull request shows warning when using the paths m/45'/coin_type'/account'/[0-1000000]/change/address_index and m/45'/coin_type/account/[0-1000000]/change/address_index with SPENDADDRESS and multisig.

Is it intentional?

[Shadouts]

I found two differences to how this is implemented in core:

• This pull request completely disables using the paths m/45'/coin_type'/account'/[0-1000000]/change/address_index and m/45'/coin_type/account/[0-1000000]/change/address_index for singlesig.
• This pull request shows warning when using the paths m/45'/coin_type'/account'/[0-1000000]/change/address_index and m/45'/coin_type/account/[0-1000000]/change/address_index with SPENDADDRESS and multisig.

Is it intentional?

Yes. Unchained does not support p2pkh spends. Also, how would a spend ever be InputScriptType_SPENDADDRESS and has_multisig at the same time? My interpretation is that InputScriptType_SPENDADDRESS indicates p2pkh and therefore it will never be has_multisig == true.

[onvej-sl]

I'm not entirely sure, but I believe that if has_multisig == true, then InputScriptType_SPENDADDRESS is interpreted the same as InputScriptType_SPENDMULTISIG. See for example this.

However, my point is not that this is incorrect. The point is that I think the behaviour implemented in this pull request for the legacy firmware differs from the behaviour implemented here. I am uncertain whether the difference is intentional.

[Shadouts]

@onvej-sl I've pushed a change which I think restores the logic from previous, however, it's still not clear to me how this pathway would ever evaluate to true if InputScriptType_SPENDADDRESS and has_multisig, but at least it's there to address any possible regression.

[matejcik]

so i'm curious: the PR says "support unchained paths", but you seem to be adding restrictions here. Previously the same paths on a Trezor One would be supported on any script type, now we're discussing which script types to keep allowed?

[onvej-sl]

so i'm curious: the PR says "support unchained paths", but you seem to be adding restrictions here. Previously the same paths on a Trezor One would be supported on any script type, now we're discussing which script types to keep allowed?

It depends on what you mean by "supported". If "supported" means you can use the path with safety checks enabled and no warning is displayed, then the paths weren't previously supported for all script types. If "supported" means you can use the path with safety checks turned off or you don't care about the warning, then this pull request restricts the paths to multisig (see this and this), which differs from how this was implemented in core and I believe this is not intentional.

[Shadouts]

What restrictions are being added? This increases the scope of the Unchained paths check to include InputScriptType_SPENDWITNESS

The only conditional difference is on line 577 where InputScriptType_SPENDWITNESS is now allowed. All other conditional checks should be identical for address_n[0] == PATH_HARDENED + 45 && address_n_count == 6

[onvej-sl]

The other difference is here. However, I don't know if this is what @matejcik meant.

[matejcik]

yeah, my bad. i didn't notice that there was a common "if full" block in the previous version.
in that case, yes, the current version of the code looks fine to me.

it's still not clear to me how this pathway would ever evaluate to true if InputScriptType_SPENDADDRESS and has_multisig

again, callers are explicitly allowed to use SPENDADDRESS and provide multisig data, which sets has_multisig flag and is treated as multisig. (this is actually the same behavior as SPENDWITNESS, where you also indicate multisig-ness by providing the multisig data and not by using a special script type. the existence of SPENDMULTISIG is a historical artifact)

[onvej-sl]

A got a bit lost in this discussion.

I would like to ask @Shadouts, whether you want to allow the use of m/45'/coin_type'/account'/[0-1000000]/change/address_index and m/45'/coin_type/account/[0-1000000]/change/address_index for singlesig provided the user ignored this warning.

I'm asking because it is allowed in core but not in this pull request.

[Shadouts]

@onvej-sl To answer your question, Unchained has no use for singlesig at those paths. Our only concern is with multisig.

But, I don't see how it differs from core. Both conditions are checking has_multisig in legacy and multisig in core.