Custom Script Accounts: lower level APIs

[tiero]

TL;DR

marina.createAccount('my-account@v2')
marina.useAccount('my-account@v2')
marina.getPublicKey() // { publicKey, derivationPath }

// web app generate his own script creation with it
// like using Ionio etc..

marina.importContract({ script, template, constructorParams, derivationPath })
marina.signSchnorr({ sighash, derivationPath })

Reasons

• Adding multiple accounts for little variations of the script template and/or is constructor parameters is a bit of too much effort
• sometimes you do not want to have marina to generate scripts for you, so it's ok to have web apps to import scripts from outside
• This increases possibility mobile apps/hardware wallet could follow this approach

What happens

• user MUST call importContract if want marina to sign/spend it & track coins
• a single account, can have different script templates, one for each public key potentially
• getNextAddress: not clear what should return, this should be discussed

Please @louisinger @altafan @bordalix tell me your thoughts

[louisinger]

• Adding multiple accounts for little variations of the script template and/or is constructor parameters is a bit of too much effort
• sometimes you do not want to have marina to generate scripts for you, so it's ok to have web apps to import scripts from outside

An alternative could be to drop importContract and pass the contract as parameter in getNextAddress calls (exactly like we did for the constructorParams array in fact). Thus, custom script accounts becomes only a BIP32 keys tree derived from the account name:

marina.createAccount('my-account@v2')
marina.useAccount('my-account@v2')
// I don't need any template/contract to do this:
marina.getPublicKey() // { publicKey, derivationPath }
marina.signSchnorr({ sighash, derivationPath })

Then, either the webapp is responsible to generate the script and "send" to marina the generated script. Maybe associated to a derivation path for signing "simple scripts" :thinking:

marina.registerScript('my-account@v2', scriptDerivationPath, script)

Or the webapp use template-based derivation for the next account path:

marina.useAccount('my-account@v2')
marina.getNextAddress({ template, constructorParams }) 
// marina generates the script and map it with next derivation path

TL;DR template becomes an address parameter instead of account parameter. What do you think? @tiero @bordalix

[tiero]

marina.signSchnorr({ sighash, derivationPath })

This may be very dangerous, if we do not also attach /share the full transaction (ie. pre hashing it) so in the popup we can do the job of hashing to prove and display the verified tx (ie. inputs & outoputs)

marina.getNextAddress({ template, constructorParams })

So, if no template & params passed, we default to the a specific script ie.wpkh and we fetch the public key ourselves? It means an account, can have any possible template? How the restore would look like? We need to keeo track of each derivation path what script template & params used?

Other than that works for me.

[louisinger]

marina.signSchnorr({ sighash, derivationPath })

This may be very dangerous, if we do not also attach /share the full transaction (ie. pre hashing it) so in the popup we can do the job of hashing to prove and display the verified tx (ie. inputs & outoputs)

OK to attach base64 pset & input index with sighash in order to let Marina recomputes the message before signing but it prevents the app to get non-sighash signature. Some templates could expect timestamps or external data to be signed by Marina isn't it ?

marina.getNextAddress({ template, constructorParams })

So, if no template & params passed, we default to the a specific script ie.wpkh and we fetch the public key ourselves?

I would just throw an error if no template. If the user expects wpkh, he should pass a wpkh template. We could also set up a fallback template at createAccount step.

It means an account, can have any possible template?

Yes. is it a problem? It solves lot of migration problem if the app updates its template and want to keep using the same coins/account.

How the restore would look like? We need to keeo track of each derivation path what script template & params used?

Yes we need a kind of "backup file" containing all the data. If we see template + params compiled as an output descriptor it means a list of descriptors for each account.

[tiero]

I would just throw an error if no template

This is a breaking change with the old API right? Would try to not do it

Yes. is it a problem?

I guess mandates keeping precise metadata when backing up a mnemonic. But I guess is acceptable, since we must do anyway for contract params #391