Hardware wallet extensions for PSET

[miketlk]

This is a proposal for the new ELIP specifying additional PSET fields useful for integration with hardware wallets or similar airgapped devices. By implementing the Signer role, these devices by design have no access to the network, and thus solely rely on the information present in PSET. Particularly, including asset metadata like ticker and precision is crucial for displaying adequate information to the users on the transaction they are about to sign.

[philippem]

The requirement to communicate asset metadata in the PSET is probably not unique to hardware wallets. Maybe the field name could be generalized and the applicability of the ELIP expanded?

@apoelstra thoughts?

[apoelstra]

I think we need to step back and take a holistic view of PSET, what workflows it should support, etc., and come up with a coherent plan for all the fields that it should support. I'm happy to review this and give it an ELIP number, but I don't have the view of how we're planning to use this, or the time, to say whether this proposal is something we want to implement in Elements.

We've added several fields over the last fiew months based on direct requests from users to add the fields, but I don't think this sort of ad-hoc extension strategy is sustainable. (I'm not saying that's what this is! But I'm saying that I can't make a judgement call.)

[apoelstra]

It looks like this is missing a Backward Compatibility section.

[miketlk]

I don't think it is necessary for Elements to implement these extensions. It would be more logical to support them at the level of client software, such as Blockstream Green. Although support in Elements would be convenient for automated generation of test data for HWW app, as I do now using RPC calls.

[miketlk]

It looks like this is missing a Backward Compatibility section.

@apoelstra, thank you for looking through the draft. I will add Backward Compatibility section. It seems to me it should be trivial because the only new field is optional. Existing implementations should ignore it, as they do for each field with unknown key. The newer implementations, for which these extensions matter, should not rely on the presence of this field.

[apoelstra]

I will add Backward Compatibility section. It seems to me it should be trivial because the only new field is optional.

Yep, that's my impression as well :). But I'd still like a sentence or two saying this, then I'm happy to assign this an ELIP number (unless @tiero jumps in to say that I shouldn't be assigning numbers since I'm not listed in ELIP2 as a maintainer :))

[miketlk]

@apoelstra, please check commit bb1f245

[tiero]

@apoelstra I would love to have you, maintainer, as well (I proposed myself back in April to try to push to have this venue, the more people can be involved, the better)

[apoelstra]

@miketlk looks good to me.

Let's give this ELIP 100 (we'll reserve the <100 numbers for "process" things). Could you add a commit which moves the file to the new name and updates the header?

[miketlk]

Ok. Done in 06407a1