Support mainnet or testnet addresses on any derivation path

[kyranjamie]

I don't believe there's an immediate rush for this feature, however inline with the expected behaviour of our addressing conventions, we do need to be able to specify network in addition to derivation path.

This could be in the form of an additional flag passed to the device.

[kyranjamie]

To add to this, I don't believe I'm able to generate testnet address even with the testnet path. Using m/44'/1'/0/0/0 still returns mainnet addresses.

[neithanmo]

Hi @kyranjamie. so if I understood well, we want to generate a testnet address for any derivation path. Your idea is passing a flag for such a case, right? can you elaborate a bit more?

[kyranjamie]

Hi @neithanmo, yeah that's pretty much it. From a consumer point of view:

Here's what we have now:

sign(path: string, message: Buffer): ResponseSign

here's what we're after

sign(path: string, network: 'testnet' | 'mainnet', message: Buffer): ResponseSign

Stacks doesn't follow BIP-44 exactly, which is why we need this behaviour.

[neithanmo]

This flag or network information is already part of the transaction structure,, isn't it?
so with this new flag, should we ignore the one in the transaction?

[kyranjamie]

Good point. If we can infer chain from the tx, and keep the API as it is now, that would be great.

[neithanmo]

I think, this line sets the transaction version number. I did the next two experiments:

• const network = StacksTestnet, and same derivation path
  I got:
  

then:

• const network = StacksMainnet(), keep using the same path at it is in the example, and got:
  

Not sure If this is the expected behavior. I guess ST stands for testnet and SP for mainnet ??

[kyranjamie]

Sorry @neithanmo sign wasn't particularly demonstrative of this issue.

Consider the address generation methods, such as showAddressAndPubKey. Currently it only accepts a derivation path. Ideally we need a signature like showAddressAndPubKey(path: string, network: 'testnet' | 'mainnet').

[neithanmo]

Ok, I see that function. Yes, It seems that we can not generate a testnet address there. I am not well versed in JS, but maybe we can define an overloaded function, and have another backend function on the ledger internal side, that allows us to pass in this flag. let me dig a bit more at what we have internally, and how we can overcome this issue.

[neithanmo]

as an update. #55 is a wip that addresses this.