@bsv/sdk 1.0.18 → 1.0.20

package/docs/concepts/HOW_TX.md

@@ -0,0 +1,60 @@
+# How are Transactions Built with Inputs and Outputs?
+
+Transactions are the fundamental entities within the blockchain, acting as the mechanism through which value is transferred across the network. Understanding how transactions are built using inputs and outputs is crucial for developers, as this process encompasses the core of creating, signing, and sending transactions within applications.
+
+## Understanding Transactions
+
+A **transaction** in BSV is a record that transfers some outputs containing Bitcoins from one state to the next. However, unlike traditional banking systems, these transactions aren't direct debits or credits to an account. Instead, they reference outputs created by previous transactions as thrir inputs and create new outputs as future spendable coins.
+
+### Transaction Structure
+
+Each transaction consists of the following components:
+
+- **Version**: Indicates the ruleset under which the transaction is validated, or which overlay network(s) it belongs to.
+- **Inputs**: List of references to outputs from previous transactions, showing where the bitcoins being sent were previously stored.
+- **Outputs**: List of allocations of bitcoins, specifying the amount and conditions under which they can be spent in the future.
+- **Lock Time**: An optional setting that specifies the earliest time or block number at which the transaction can be valid.
+
+Transactions can also be attached to a **Merkle proof** to provide proof of inclusion in a particular block, after they have been processed.
+
+## Inputs and Outputs
+
+Inputs and outputs are the essential elements that make up a transaction. Understanding their structure and usage is key to mastering transaction creation and manipulation using the BSV SDK.
+
+### Transaction Inputs
+
+A **Transaction Input** includes the following fields:
+
+- **Source Transaction ID**: The transaction ID (TXID) from which the input bitcoins are derived.
+- **Source Output Index**: Specifies which output from the referenced transaction is to be spent.
+- **Unlocking Script**: Contains signatures or other unlocking solutions that prove the right to spend the referenced previous output.
+- **Sequence**: A number that can be used to allow transaction inputs to be updated before finalization, if it's less than 0xFFFFFFFF.
+
+Inputs connect a new transaction back to the point in the blockchain where the bitcoins were previously recorded as outputs.
+
+### Transaction Outputs
+
+A **Transaction Output** consists of:
+
+- **Satoshis**: The amount of BSV being transferred.
+- **Locking Script**: Defines the conditions under which the output can be spent, such as requiring a digital signature from the recipient's public key.
+
+Outputs create spendable coins that can be used as inputs in future transactions.
+
+## Constructing a Transaction
+
+Creating a transaction involves several clear steps, utilizing inputs and outputs to dictate where bitcoins are moving from and to:
+
+1. **Define Outputs**: Decide the amount of BSV to transfer and the conditions under which the transfer can later be spent.
+2. **Select Inputs**: Identify previous transaction outputs to spend that have enough balance to cover the outputs and the transaction fee.
+3. **Calculate Fees**: Estimate the necessary transaction fee based on transaction size, where you will be broadcasting, and the level of service priority you require.
+4. **Generate Change**: If inputs exceed the sum of outputs and fees, create change output(s) sending the excess back to the sender without re-using keys.
+5. **Unlock Inputs**: Utilize the private keys or other mechanisms associated with the inputs you're spending to unlock each one, thereby authorizing the bitcoins to be spent.
+6. **Complete Unlocking**: In cases of multi-party transactions, pass the transaction around to all needed parties for unlocking.
+7. **Broadcast**: Send the final signed transaction to the BSV network for inclusion in a block, and register it with overlay networks as required.
+
+Each of these steps is facilitated by the BSV SDK, which provides comprehensive tools and templates to handle the complexities of transaction creation, from generating cryptographic signatures to managing network broadcast clients.
+
+## Conclusion
+
+The BSV SDK empowers developers to build robust applications on the network by abstracting the complexities of transaction creation. By understanding how transactions are structured and built through inputs and outputs, developers can leverage the full potential of the BSV blockchain, ensuring secure, efficient, and scalable applications. You can check out an example of creating transactions [in this tutorial!](../examples/EXAMPLE_COMPLEX_TX.md)

package/docs/concepts/OP.md

@@ -0,0 +1,38 @@
+# Opcodes and Their Functionality Within Bitcoin Script
+
+## Introduction
+BSV is underpinned by a powerful scripting language that plays a crucial role in securing transactions. This language, which defines the conditions under which coins can be spent, relies heavily on "opcodes" — operational codes that manipulate and evaluate data. This document aims to demystify the functionality of these opcodes, providing examples of their use.
+
+## Securing Coins with Script Predicates
+Scripts secure coins through predicates. A predicate is essentially a condition that must be met for coins to be spent. In Bitcoin, these conditions are defined using a scripting language that determines how and when the coins can be transferred. The scripts ensure that only the rightful owner of the coins can spend them by satisfying the conditions laid down in the script attached to each coin or output.
+
+## Script Execution Environment: Stacks and Scripts
+Bitcoin's scripting system operates in a stack-based execution environment. This means that the script processes data using two primary structures:
+- **Main stack:** Where most operations are performed.
+- **Alt stack:** Used occasionally to provide additional stack flexibility.
+
+Scripts in Bitcoin are divided into two parts:
+1. **Unlocking script:** Provided by the spender of the coins, this script supplies the data needed to satisfy the conditions of the locking script.
+2. **Locking script:** Placed by the recipient in a transaction output, this script sets the conditions under which the coins can be spent.
+
+The execution begins with the unlocking script, which places data on the stack. Following this, the locking script is appended and continues to operate on the same stack. The spend is considered valid if, at the end of execution, the top of the stack holds a "true" value (non-zero).
+
+## Understanding Opcodes
+Opcodes are the operational codes used within a script to perform specific functions on the data in the stacks. Each opcode manipulates stack data to perform operations such as addition, subtraction, logical comparisons, cryptographic hashes, signature checks, and more. After executing an opcode, the results are pushed back onto the stack, altering its state for subsequent operations.
+
+### Examples of Common Opcodes
+- **OP_ADD:** Pops the top two items off the stack, adds them, and pushes the result back onto the stack.
+- **OP_EQUAL:** Pops the top two items, compares them, and pushes `1` (true) if they are equal, or `0` (false) otherwise.
+- **OP_HASH256:** Pops the top item, computes its double SHA-256 hash, and pushes the result back onto the stack.
+- **OP_CHECKSIG:** Pops a public key and a signature from the stack and checks if the signature is valid for the given public key and wider transaction; pushes `1` if the signature is valid.
+
+These opcodes are foundational for enabling complex scripting capabilities in BSV, allowing for the creation of various types of transactions including multi-signature wallets, escrow arrangements, sCrypt smart contracts, and much more.
+
+## Combining Opcodes to Secure Coins
+The true power of scripting comes from the combination of opcodes to form complex predicates. These predicates secure the coins by requiring that certain conditions be met before the coins can be spent. For example, a script might require that a transaction be signed by multiple parties (multi-signature), or that a certain amount of time elapse before the coins can be spent (timelocks).
+
+### Implementing Cryptographic Primitives
+Opcodes also implement various cryptographic primitives such as digital signatures and hashing. These primitives are essential for maintaining the security and integrity of transactions on the blockchain. For instance, the `OP_CHECKSIG` opcode is crucial for verifying that a transaction is authorized by the holder of the private keys associated with the coins being spent.
+
+## Conclusion
+By understanding the functionality of opcodes within the Bitcoin scripting language, users and developers can appreciate the flexibility and security that Bitcoin scripts provide. You can check out [this example](../examples/EXAMPLE_VERIFYING_SPENDS.md) of how to validate spends within the BSV SDK.

package/docs/concepts/README.md

@@ -0,0 +1,14 @@
+# Conceptual Topics
+
+These documents cover high-level conceptual information that will augment developers' understanding of the code-level SDK documentation:
+
+- [What is BEEF and why is it useful?](BEEF.md)
+- [What is a Transaction Signature?](TX_SIG.md)
+- [What is Type-42 and How Does it Enable Private Signatures?](./42.md)
+- [What are Script Templates Used for?](TEMPLATES.md)
+- [How are Transactions Built with Inputs and Outputs?](HOW_TX.md)
+- [The Role of Chain Trackers within the SPV Ecosystem](CHAIN_SPV.md)
+- [How Does Transaction Fee Modeling Work?](FEE.md)
+- [How are Bitcoin Transactions Validated?](TX_VALID.md)
+- [Opcodes and Their Functionality Within Bitcoin Script](OP.md)
+- [What are Hashes and Why are they Important in Bitcoin?](HASHES.md)

package/docs/concepts/TEMPLATES.md

@@ -0,0 +1,42 @@
+# What are Script Templates Used for?
+
+Script templates play a critical role in facilitating the creation and management of scripts that control the locking and unlocking of UTXOs (transaction outputs or tokens in BSV). These scripts are integral to implementing the various transaction protocols on the blockchain, adhering to Bitcoin's original vision while enhancing security, scalability, and efficiency.
+
+## The Role of Scripts in BSV
+
+Scripts are pieces of code that define the conditions under which funds can be spent on the blockchain. Every transaction on the BSV network includes two kinds of scripts:
+- **Locking Scripts**: These scripts set conditions under which coins can be spent. They are included in the output of a transaction.
+- **Unlocking Scripts**: These scripts satisfy the conditions set by the locking scripts to spend the funds in a subsequent transaction. They are found in the input of a transaction.
+
+The purpose of these scripts is to ensure that only authorized parties can access and transact the funds by meeting predefined conditions, which may include providing a digital signature or solving a computational challenge. Any conceivable set of constraints can be programmed into a locking script.
+
+## Concept of Script Templates
+
+A script template is a predefined framework that simplifies the process of creating otherwise-potentially-complex locking and unlocking scripts. It abstracts away the underlying script construction details, allowing developers to create scripts without having to write low-level code for every new scenario. The template provides methods and properties to generate scripts dynamically based on the transaction context and the specific input parameters provided.
+
+### Components of a Script Template
+A script template generally includes the following:
+
+1. **Lock Method**: This method generates a locking script based on given parameters, such as a public key hash or other conditions defined by the transaction type (e.g., P2PKH—Pay to Public Key Hash).
+
+2. **Unlock Method**: This method creates an unlocking script, which usually involves generating a digital signature and potentially other data required to unlock the funds according to the locking script's conditions.
+
+3. **Estimate Length**: This utility provides an estimation of the unlocking script's length, which can be crucial for transaction fee calculation.
+
+## Importance of Script Templates
+
+### Simplification and Standardization
+Script templates standardize the creation of scripts, ensuring consistency and reducing errors in script generation. They provide a high-level interface for commonly used script patterns, like P2PKH, reducing the need for repetitive, error-prone coding.
+
+### Security Enhancements
+By abstracting the details of script creation, script templates help in minimizing security risks associated with manual script handling. Robust templates can ensure that scripts are generated in a secure manner, adhering to the necessary cryptographic standards and best practices. Templates can also be audited for increased security, which will benefit everyone who relies upon it.
+
+### Scalability and Efficiency
+Script templates enable developers to quickly implement and deploy blockchain solutions on a large scale. They reduce the complexity involved in script creation, allowing developers to focus on building applications rather than dealing with the intricacies of script coding.
+
+### Flexibility
+Templates are designed to be flexible and extensible, accommodating various transaction types and conditions without significant modifications to the underlying codebase. This flexibility is crucial for adapting to evolving use cases and requirements in the BSV ecosystem.
+
+## Conclusion
+
+Script templates are fundamental tools within the BSV SDK that streamline the development of on-chain use-cases by providing robust, secure, and efficient methods for handling transaction scripts. They encapsulate the complexity of script creation and ensure that developers can focus on higher-level application logic, thereby accelerating the development process and enhancing the capabilities of their implementations. To get started with script templates in the TypeScript SDK, [check out this tutorial!](../examples/EXAMPLE_SCRIPT_TEMPLATES.md)

package/docs/concepts/TX_SIG.md

@@ -0,0 +1,34 @@
+# What are Transaction Signatures?
+
+Transaction signatures play a crucial role in securing transactions and establishing trust between parties. These digital signatures serve as a powerful tool for validating the authenticity and integrity of spends on the blockchain. This document delves into the concept of transaction signatures, breaking down their components, functionality, and significance in a way that's (hopefully) accessible to a fairly broad audience.
+
+## Introduction to Digital Signatures
+
+Before diving into transaction signatures, it's essential to understand the basics of digital signatures. A digital signature is akin to a fingerprint; it is a unique mark that an individual can use to sign digital documents or transactions. Just as a handwritten signature authenticates the identity of the signer and their consent to the document's terms, a digital signature ensures that a digital document or transaction is authentic and hasn't been tampered with after the signature was made.
+
+## Components of Transaction Signatures
+
+Transaction signatures in BSV are a special type of digital signature. They consist of several key components:
+
+- **r and s values**: These two values constitute the core of the ECDSA (Elliptic Curve Digital Signature Algorithm) signature. They are derived from the private key of the sender and the transaction data. Together, they verify that the owner of the corresponding public key has authorized the transaction.
+- **SIGHASH flags**: Transaction signatures also include SIGHASH flags, which specify how much of the transaction data is covered by the signature. These flags allow signers to control which parts of the transaction they are committing to when they sign it, and which ones might be updated later.
+
+## Understanding SIGHASH Flags
+
+SIGHASH flags provide flexibility in how transactions are signed, offering several options:
+
+- **SIGHASH_ALL**: This is the default mode, where the signature covers all the inputs and outputs of the transaction. It indicates the signer's commitment to the exact details of the transaction, including the amount and script associated with each output.
+- **SIGHASH_NONE**: With this flag, the signature covers all inputs but no outputs, allowing others to add or modify outputs. This could be used in scenarios where the signer is indifferent to where the funds are going.
+- **SIGHASH_SINGLE**: This mode signs only one input and one output, the one with the same index as the signed input. It is useful for transactions with multiple participants, allowing each to sign only for their part.
+- **SIGHASH_ANYONECANPAY**: This flag can be combined with the others and indicates that the signature covers only the current input, allowing others to add more inputs to the transaction.
+
+## The Role of Transaction Signatures
+
+Transaction signatures serve two primary purposes on the BSV network:
+
+1. **Authentication**: By signing a transaction with their private key, the sender proves they hold the private keys needed by the locking script that secures the funds they're attempting to spend.
+2. **Integrity**: Once a transaction is signed, any alteration to the parts that were signed would invalidate the signature. This property ensures that once a transaction is broadcasted to the network, it cannot be tampered with or altered by malicious actors.
+
+## Conclusion
+
+Transaction signatures are at the heart of the security and trust model of blockchain technology. They enable the secure transfer of digital assets between parties without the need for a central authority. By understanding the components and functionality of transaction signatures, users and developers can better appreciate the sophisticated mechanisms that keep the BSV network secure and trustworthy. You can learn more about how transaction signatures work within the TypeScript BSV SDK [here](../low-level/TX_SIG.md).

package/docs/concepts/TX_VALID.md

@@ -0,0 +1,35 @@
+# How are Bitcoin Transactions Validated?
+
+Understanding the intricacies of Bitcoin transaction validation is crucial for developers building systems that receive and process them within the ecosystem. This document will delve into the foundational concepts surrounding Bitcoin transactions, peer-to-peer exchange, and Simplified Payment Verification (SPV), as well as the critical validation processes that underpin the BSV network's scaling model.
+
+## Introduction
+
+Bitcoin transactions are the lifeblood of the network, enabling the transfer of value between participants without the need for central intermediaries. Each transaction on the Bitcoin SV blockchain is verified through a series of cryptographic checks and balances that ensure its authenticity and compliance with network rules.
+
+### Key Concepts
+
+- **Transactions:** These are data structures that encode the transfer of value between participants in the network.
+- **Peer-to-Peer Exchange:** Direct interaction between participants' wallets without the need for a central authority, in which transactions and associated merkle proofs are sent back and forth.
+- **SPV (Simplified Payment Verification):** A method for validating transactions that does not require downloading the entire blockchain, facilitating more scalable applications.
+
+## The Transaction Validation Process
+
+Validating a Bitcoin transaction involves several critical steps that confirm its legitimacy and adherence to the rules set by the network. Here's a breakdown of the validation process:
+
+1. **Script Execution:**
+   - Each input in a transaction has an unlocking script that must successfully execute and validate against the locking script of the output it is spending.
+   - The result of this script execution must be true, indicating that the conditions to spend the output are met.
+
+2. **Transaction Outputs vs. Inputs:**
+   - The total value of outputs must not exceed the total value of inputs, ensuring that no new money is created out of thin air, except for the coinbase transaction, which includes the block reward.
+   - Check that the transaction includes enough fee to be included in a block, as miners prioritize transactions with higher fees.
+
+3. **Merkle Path Verifications:**
+   - Each input must be traceable back to a transaction included in a block, verified through a Merkle path.
+   - This ensures that each input used is legitimate and recognized by the network as having been previously confirmed.
+
+4. **Checking Locktime and Sequence:**
+   - Transactions may include locktime and sequence numbers that impose conditions on the earliest time or block height at which a transaction can be added to the blockchain.
+   - Proper handling of these parameters ensures that transactions are processed in a timely and orderly manner.
+
+You can check out an example using the TypeScript SDK where a transaction is verified according to these rules [here](../examples/EXAMPLE_VERIFYING_BEEF.md).

package/docs/examples/EXAMPLE_HD_WALLETS.md

@@ -21,7 +21,7 @@ console.log(randomKey.toString())
 You can also import an existing key as follows:
 
 ```typescript
-const importedKey = new HD().fromString('xprv...')
+const importedKey = HD.fromString('xprv...')
 ```
 
 Now that you've generated or imported your key, you're ready to derive child keys.
@@ -31,7 +31,7 @@ Now that you've generated or imported your key, you're ready to derive child key
 BIP32 child keys can be derived from a key using the `.derive()` method. Here's a full example:
 
 ```typescript
-const key = new bsv.HD().fromString('xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V')
+const key = HD.fromString('xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V')
 const child = key.derive('m/0/1/2')
 console.log(child.toString())
 // 'xprv9yGx5dNDfq8pt1DJ9SFCK3gNFhjrL3kTqEj98oDs6xvfaUAUs3nyvVakQzwHAEMrc6gg1c3iaNCDubUruhX75gNHC7HAnFxHuxeiMVgLEqS'
@@ -44,7 +44,7 @@ Any of the standard derivation paths can be passed into the `.derive()` method.
 XPRIV keys can be converted to normal `PrivateKey` instances, and from there to WIF keys. XPUB keys can be converted to normal `PublicKey` instances, and from there to Bitcoin addresses. XPRIV keys can also be converted to XPUB keys:
 
 ```typescript
-const key = new bsv.HD().fromString('xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V')
+const key = HD.fromString('xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V')
 
 // Convert XPRIV to XPUB
 const xpubKey = key.toPublic()
@@ -68,4 +68,4 @@ This guide has demonstrated how to use BIP32 for key derivation and format conve
 
 ## Disadvantages and Risks
 
-BIP32 allows anyone to derive child keys if they know an XPUB. The number of child keys per parent is limited to 2^31, and there's no support for custom invoice numbering schemes that can be used when deriving a child, only a simple integer. Finally, BIP32 has no support for private derivation, where two parties share a common key universe no one else can link to them, even while knowing the master public key. It's for these reasons that we recommend the use of type-42 over BIP32. You can read an equivalent guide [here](EXAMPLE_TYPE_42.md).
+BIP32 allows anyone to derive child keys if they know an XPUB. The number of child keys per parent is limited to 2^31, and there's no support for custom invoice numbering schemes that can be used when deriving a child, only a simple integer. Finally, BIP32 has no support for private derivation, where two parties share a common key universe no one else can link to them, even while knowing the master public key. It's for these reasons that we recommend the use of type-42 over BIP32. You can read an equivalent guide [here](EXAMPLE_TYPE_42.md).

package/docs/transaction.md

@@ -442,6 +442,8 @@ export default class Transaction {
     toHex(): string 
     toHexBEEF(): string 
     hash(enc?: "hex"): number[] | string 
+    id(): number[];
+    id(enc: "hex"): string;
     id(enc?: "hex"): number[] | string 
     async verify(chainTracker: ChainTracker | "scripts only"): Promise<boolean> 
     toBEEF(): number[] 
@@ -605,6 +607,35 @@ Argument Details
 
 #### Method id
 
+Calculates the transaction's ID in binary array.
+
+```ts
+id(): number[]
+```
+
+Returns
+
+- The ID of the transaction in the binary array format.
+
+#### Method id
+
+Calculates the transaction's ID in hexadecimal format.
+
+```ts
+id(enc: "hex"): string
+```
+
+Returns
+
+- The ID of the transaction in the hex format.
+
+Argument Details
+
++ **enc**
+  + The encoding to use for the ID. If 'hex', returns a hexadecimal string.
+
+#### Method id
+
 Calculates the transaction's ID.
 
 ```ts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bsv/sdk",
-  "version": "1.0.18",
+  "version": "1.0.20",
   "type": "module",
   "description": "BSV Blockchain Software Development Kit",
   "main": "dist/cjs/mod.js",

package/src/compat/HD.ts

@@ -84,6 +84,16 @@ export default class HD {
     return new this().fromRandom()
   }
 
+  /**
+   * Initializes the HD wallet from a given base58 encoded string.
+   * This method decodes a provided string to set up the HD wallet's properties.
+   * @param str - A base58 encoded string representing the wallet.
+   * @returns {HD} The new instance with properties set from the string.
+   */
+  public static fromString (str: string): HD {
+    return new this().fromString(str)
+  }
+
   /**
      * Initializes the HD wallet from a given base58 encoded string.
      * This method decodes a provided string to set up the HD wallet's properties.
@@ -96,13 +106,13 @@ export default class HD {
   }
 
   /**
-     * Converts the HD wallet to a base58 encoded string.
-     * This method provides a string representation of the HD wallet's current state.
-     * @returns {string} A base58 encoded string of the HD wallet.
-     */
-  public toString (): string {
-    const bin = this.toBinary()
-    return toBase58Check(bin, [])
+   * Initializes the HD wallet from a seed.
+   * This method generates keys and other properties from a given seed, conforming to the BIP32 specification.
+   * @param bytes - An array of bytes representing the seed.
+   * @returns {HD} The current instance with properties set from the seed.
+   */
+  public static fromSeed (bytes: number[]): HD {
+    return new this().fromSeed(bytes)
   }
 
   /**
@@ -132,21 +142,21 @@ export default class HD {
   }
 
   /**
-     * Initializes the HD wallet from a seed.
-     * This method generates keys and other properties from a given seed, conforming to the BIP32 specification.
-     * @param bytes - An array of bytes representing the seed.
-     * @returns {HD} The current instance with properties set from the seed.
-     */
-  public static fromSeed (bytes: number[]): HD {
-    return new this().fromSeed(bytes)
+   * Initializes the HD wallet from a binary buffer.
+   * Parses a binary buffer to set up the wallet's properties.
+   * @param buf - A buffer containing the wallet data.
+   * @returns {HD} The new instance with properties set from the buffer.
+   */
+  public static fromBinary (buf: number[]): HD {
+    return new this().fromBinary(buf)
   }
 
   /**
-     * Initializes the HD wallet from a binary buffer.
-     * Parses a binary buffer to set up the wallet's properties.
-     * @param buf - A buffer containing the wallet data.
-     * @returns {HD} The current instance with properties set from the buffer.
-     */
+   * Initializes the HD wallet from a binary buffer.
+   * Parses a binary buffer to set up the wallet's properties.
+   * @param buf - A buffer containing the wallet data.
+   * @returns {HD} The current instance with properties set from the buffer.
+   */
   public fromBinary (buf: number[]): this {
     // Both pub and private extended keys are 78 buf
     if (buf.length !== 78) {
@@ -176,6 +186,16 @@ export default class HD {
     return this
   }
 
+  /**
+   * Converts the HD wallet to a base58 encoded string.
+   * This method provides a string representation of the HD wallet's current state.
+   * @returns {string} A base58 encoded string of the HD wallet.
+   */
+  public toString (): string {
+    const bin = this.toBinary()
+    return toBase58Check(bin, [])
+  }
+
   /**
      * Derives a child HD wallet based on a given path.
      * The path specifies the hierarchy of the child key to be derived.