Glossary - Bitpanda Enterprise

TERM	EXPLANATION
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 transactions for a particular wallet, as defined in the policy's delegate schedules. Delegates cannot approve policy changes
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. Keys must be on the `secp256r1` curve (see Public Key for the format)
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	The secret half of an ECDSA key pair, used to produce signatures. It must never be shared; the corresponding Public Key can be derived from it
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	`quorumCount`: the number of signatures, s, required by a clause where 1 <= s <= keys.length
prime256v1	Another name for the `secp256r1` curve (see secp256r1)
Recoverers	The set of key(s), also known as wallet admins, that are allowed to approve policy changes (e.g. key rotation or recovery) for a particular wallet, as defined in the policy's recoverer schedules. Recoverers cannot authorise transactions
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
TCSS	Transaction Co-Signing Service. Enforces wallet-level rules such as Address Book destination allowlisting before a transaction is submitted; see Policies and Signing
secp256k1	The particular elliptic curve that Bitcoin and Ethereum uses
secp256r1	The NIST P-256 elliptic curve (also known as `prime256v1`). It is used within an iOS device's secure enclave and is the curve required for all Instruction Keys
UUID	universally unique identifier (UUID) is a 128-bit number used to uniquely identify data
Wallet	A BIP32 HD key container that holds the policy governing who can sign. A wallet holds assets via its sub-wallets; see Wallets and Sub-Wallets
unverifiedDigestData	This is an object of data used during API signing. For transactions it consists of `transactionDigest`, `signData` and `shaSignData` (policy change requests have only `signData` and `shaSignData`). The `transactionDigest` is the transaction digest created using the canonical hashing form as described by the relevant chain. e.g. for Ethereum this is keccak(rlp(transaction)). The `signData` is the `transactionDigest` 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 `SHA-256(signData)`, the 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 schedules to zero keys via a `ZERO` policy change request. No keys are allowed to sign a particular wallet (i.e. locks a particular wallet account)