CIP-0021 | Restrictions on transactions signed by hardware wallets #107
Conversation
|
For the future, please do not allocate a tentative CIP number in the title - hard to juggle the titles, informal references, and which are currently ongoing under that number |
Yes - at least from our side. It might also need to be updated when multisig/native script support is added to HW wallets, which will happen before Alonzo. |
| @@ -0,0 +1,115 @@ | |||
| --- | |||
| CIP: 0021 | |||
|
PR107 is set as a REVIEW item for next week, 8/17 Editor meeting 28: if the issue is of relevance to you, consider attending the meeting or adding to the conversation here. |
CIP-0021/CIP-0021.md
Outdated
| @@ -0,0 +1,115 @@ | |||
| --- | |||
| CIP: 0021 | |||
| Title: Restrictions on transactions signed by hardware wallets | |||
There was a problem hiding this comment.
the title is a bit misleading. Rather this CIP wants to establish some best practices for HW wallets.
There was a problem hiding this comment.
Perhaps the intention is unclear and should be made clearer in the CIP. It does not comment on best practices, but lists limitations arising from hardware limitations of Trezor and especially Ledger.
The intended CIP audience are people integrating with HW wallets (developers of software wallets and similar tools), not HW wallet developers. In other words the CIP should define how you should build your transactions in order for them to be compatible (signable) with HW wallets - specifically Ledger and Trezor (not sure if there are other significant ones currently). In general, the rules should be a superset of restrictions for each HW wallet, so if you follow this CIP, you would be compatible with all HW wallets, and if you don't, you risk that some parties use HW wallets and will not be able to sign your transaction. This is especially important in context of transactions signed by multiple parties.
There was a problem hiding this comment.
I'd suggest using the term "interoperability" in the title, e.g. "Transaction guidelines for interoperability with hardware wallets".
|
We added “Optional empty lists and maps”, “Outputs” and “Auxiliary data” sections due to an issue reported to the Cardano LedgerJS project - vacuumlabs/ledgerjs-cardano-shelley#125 - outputs with no multi-assets contained the empty multiasset map which caused a tx hash mismatch on Ledger which doesn’t include it. 81d2394 |
CIP-0021/CIP-0021.md
Outdated
|
|
||
| **Integers** | ||
|
|
||
| While the Cardano CDDL specification usually does not limit the size of integers, HW wallets only support `int64` for signed integers and `uint64` for unsigned integers. Any integer value must fit in the appropriate type. |
There was a problem hiding this comment.
Alas... I am still not sure whether unbounded integers on the blockchain was a good idea in the first place 😶
There was a problem hiding this comment.
We do limit the size in the CDDL, usually to signed or unsigned int 64. There are only a few places where we allow "big ints". See the big_int type definition in the Alonzo CDDL.
And note that those big ints are themselves bounded to 64 bytes. This is for Plutus integer data.
There was a problem hiding this comment.
And note that those big ints are themselves bounded to 64 bytes.
That's good to know actually.
| [ transaction_metadata: { * transaction_metadatum_label => transaction_metadatum }, auxiliary_scripts: [ * native_script ]] | ||
| ``` | ||
|
|
||
| The `auxiliary_scripts` must be an array of length 0. |
There was a problem hiding this comment.
Is that something which is in the making, or there's no plan to support auxiliary_scripts ever? That may be quite limiting for Plutus.
There was a problem hiding this comment.
If auxiliary_scripts support is needed on HW wallets it should be added. Currently it's not supported and so it is a restriction on the transactions.
CIP-0021/CIP-0021.md
Outdated
| There are two limits on the number of witnesses: | ||
|
|
||
| - an absolute limit of `UINT16_MAX`, i.e. 65535; | ||
| - a relative limit dependent on the transaction body (essentially one witness per each input, each withdrawal and each certificate in a typical transaction). |
There was a problem hiding this comment.
This second condition may be overly restrictive in Alonzo where it'll be allowed to request additional signatures which do not correspond to any input. This would be however specified by a dedicated field on transactions required_signers (key 14 in transaction body).
There was a problem hiding this comment.
This will change with the introduction of multi-sig to HW wallets which is currently being finalised. It will be possible to send additional_witness_requests to the HW wallets which will sign the transaction with a key derived from the path given in the request.
KtorZ
changed the title
|
I've updated the CIP name and I've removed the sections regarding witnesses since this isn't true anymore. 74bb782 |
|
This PR was Reviewed last Editor meeting (28) - see notes. |
There was a problem hiding this comment.
LGTM.
I'd again suggest correcting the section on integers. The CDDL does say where big ints vs fixed size ints are allowed. So the the Cardano CDDL does always limit the size of integers: either big ints are not included or where they are there is a size bound on them. If you see any place where that's not the case it's a bug that we should fix.
|
I've updated the section on integers in f3d1b04. |
No description provided.