| ASN.1 |
Abstract Syntax Notation One (ASN.1) is a notation used for describing data structures that can be serialized and deserialized in a cross-platform way |
| BIP32 |
The Bitcoin Improvement Proposal (BIP) that defines The Hierarchical Deterministic (HD) key creation and transfer protocol, it allows the automatic generation of a hierarchical tree-like structure of private/public addresses (or keys) |
| Blockchain Wallet |
Wallet relating to a blockchain (i.e. Bitcoin, Ethereum) |
| Clause |
A clause in a policy schedule defines a set of keys and the minimum number of those keys required to satisfy this clause |
| Custody Signature |
An ECDSA signature representing the points r and s, which is calculated as the signature of the CustodyPrivate Key over the expression secp256k1(SHA_256(auditPrefix \|\| SHA_256(auditMessage))) |
| Delegates |
The set of key(s) that are allowed to sign a particular wallet as defined in the policy clause |
| DER |
Distinguished Encoding Rules (DER) is an ASN.1 subset of Basic Encoding Rules. It is used to produce unique octet string encoding to represent digital signatures computed on an ASN.1 value |
| Digest |
The output from a hash function. Currently expected to be either 20 or 32 bytes (40 or 64 hex characters) |
| Digest Signature |
An ECDSA signature representing the points r and s, which is calculated over a hash value resulting from a number of possible hash algorithms (including but not limited to SHA-1, SHA-256, RIPEMD-160, SHA-256 applied twice, SHA-256 over RIPEMD-160 and Ethereum's variation on SHA3-256 known as keccak) |
| ECDSA |
Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic curve cryptography to achieve similar levels of security using a smaller key size |
| HD wallet |
An HD Wallet, or Hierarchical Deterministic wallet, are wallets that uses the Hierarchical Deterministic (HD) key creation and transfer protocol as outlined in BIP32 |
| HD wallet (derivation) path |
The specific derivation path within an HD wallet that determines the associated public key. Follows a standard as defined in BIP-44 |
| HSM |
A physical computing device that safeguards and manages digital keys for strong authentication and provides crypto processing. It manages, processes, and stores cryptographic keys securely inside a hardened, tamper-resistant device |
| Instruction Key |
Every wallet created has a wallet policy which has private/public key(s) assigned to it. These keys are in the secure enclave of the iPhone device you on-boarded with. However some API users may want to NOT use the phone and change the external instruction key of the wallet policy to keys they control programmatically |
| Master Public Key |
The TrustVault provenance public key, it is used to verify the TrustVault Provenance signature |
| Policy Template |
The set of rules specifying who can sign with a particular wallet, used in trust-sign generate and trust-sign recover requests |
| Policy |
This is the resulting policy object that is derived from a policyTemplate object on a request to generate |
| Policy Signature |
An ECDSA signature representing the points r and s, which is calculated as the signature of the HSM Private Key over the DER encoding of a Policy object |
| Private Key |
An ECDSA public key in uncompressed hex format (first byte is always 04), exactly 130 hex characters (i.e. 65 bytes) that should be kept secret |
| Provenance Signature |
An ECDSA signature to acts as a proof that the message came from Bitpanda Custody and that the client is indeed the intended recipient of that message |
| Public Key |
An ECDSA public key in uncompressed hex format (first byte is always 04), exactly 130 hex characters (i.e. 65 bytes) which corresponds to a private key. A public key can be calculated from a private key, but not vice versa |
| Public Key Signature Pair |
A pair consisting of an ECDSA public key and a signature to acts as proof that message came from a particular private key holder |
| Quorum Count |
The number of signatures, s, required by this schedule where 1 <= s <= keys.length |
| prime256v1 |
Another name for the secp256r1 curve. The NIST P-256 elliptic curve is used within an iOS device's secure enclave |
| Recoverers |
The set of key(s) that are allowed to recover a particular wallet as defined in the policy clause |
| SubWallet |
A subWallet holds the assets. An HD wallet can hold multiple subWallets each with their unique HD wallet path. All subWallets inherit the policy of their parent wallet. |
| Schedule |
A schedule in a policy defines a set of clauses that all must be satisfied |
| secp256k1 |
The particular elliptic curve that Bitcoin and Ethereum uses |
| secp256r1 |
The NIST P-256 elliptic curve is used within an iOS device's secure enclave |
| UUID |
universally unique identifier (UUID) is a 128-bit number used to uniquely identify data |
| unverifiedDigestData |
This is an object of data used during API signing. It consists of digest, signData and shaSignData. The digest is the transaction digest created using the canonical hashing form as described by the relevent chain. e.g. for Ethereum this is keccak(rlp(transaction)). The signData is the digest with the wallet accountPath appended in DER format. This is TrustVault's native encoding of transaction data to ensure that only the specific wallet path (which relates directly to the sub-wallet) can use the signed data. The shaSignData is the sha3 hashed data that must be signed by the private key of the delegate. This is usually the TrustVault iOS App but can also be via API if you have an external signing key attached to your wallet policy. |
| Zero Delegate |
To change the delegate clause to zero keys. No keys are allowed to sign a particular wallet (i.e. locks a particular wallet account) |