@bsv/sdk 1.1.1 → 1.1.2

package/docs/examples/EXAMPLE_COMPLEX_TX.md

@@ -1,162 +0,0 @@
-# Example: Creating Transactions with Inputs, Outputs and Templates
-
-In Bitcoin, transactions contain inputs and outputs. The outputs are locked with scripts, and the inputs redeem these scripts by providing the correct unlocking solutions. This guide will show you how to create transactions that make use of custom inputs, outputs, and the associated script templates. For a more straightforward example, check out [how to create a simpler transaction](./EXAMPLE_SIMPLE_TX.md).
-
-## Transaction Input and Outputs
-
-All Bitcoins are locked up in Bitcoin transaction outputs. These outputs secure the coins by setting constraints on how they can be consumed in future transaction inputs. This security mechanism makes use of "scripts" — programs written in a special predicate language. There are many types of locking programs, embodying the multitude of BSV use-cases. The BSV SDK ships with a script templating system, making it easy for developers to create various types of scripts and abstracting away the complexity for end-users. You can learn about script templates [in the example](./EXAMPLE_SCRIPT_TEMPLATES.md).
-
-## Creating a Transaction
-
-To create a transaction with the SDK, you can either use the constructor:
-
-- Use the constructor and pass in arrays of inputs and outputs, or
-- Construct a blank transaction, then call the `addInput` and `addOutput` methods
-
-```typescript
-const tx = new Transaction(version, inputsArray, outputsArray, lockTime)
-// or
-const tx = new Transaction()
-    .addInput(inputA)
-    .addInput(inputB)
-    .addOutput(outputA)
-tx.version = version
-tx.lockTime = lockTime
-```
-
-Note that the version and lock time parameters are optional.
-
-## Adding Inputs and Outputs
-
-When constructing a Bitcoin transaction, inputs and outputs form the core components that dictate the flow of bitcoins. Here’s how to structure and add them to a transaction:
-
-### Transaction Inputs
-
-An input in a Bitcoin transaction represents the bitcoins being spent. It's essentially a reference to a previous transaction's output. Inputs have several key components:
-
-- **`sourceTransaction` or `sourceTXID`**: A reference to either the source transaction (another Transaction instance), its TXID. Referencing the transaction itself is always preferred because it exposes more information to the library about the outputs it contains.
-- **`sourceOutputIndex`**: A zero-based index indicating which output of the referenced transaction is being spent.
-- **`sequence`**: A sequence number for the input. It allows for the replacement of the input until a transaction is finalized. If omitted, the final sequence number is used.
-- **`unlockingScript`**: This script proves the spender's right to access the bitcoins from the spent output. It typically contains a digital signature and, optionally, other data like public keys.
-- **`unlockingScriptTemplate`**: A template that provides a method to dynamically generate the unlocking script.
-
-Next, we'll add an R-puzzle input into this transaction using the `RPuzzle`` template.
-
-#### Example: Adding an Input
-
-```typescript
-const sourceTransaction = Transaction.fromHex('...')
-const puz = new RPuzzle()
-const k = new BigNumber(1)
-const unlockingScriptTemplate = puz.unlock(k)
-let txInput = {
-    sourceTransaction,
-    sourceOutputIndex: 0,
-    unlockingScriptTemplate
-}
-
-const myTx = new Transaction()
-myTx.addInput(txInput)
-```
-
-### Transaction Outputs
-
-Outputs define where the bitcoins are going and how they are locked until the next spend. Each output includes:
-
-- **`satoshis`**: The amount of satoshis (the smallest unit of Bitcoin) being transferred. This value dictates how much value the output holds.
-- **`lockingScript`**: A script that sets the conditions under which the output can be spent. It's a crucial security feature, often requiring a digital signature that matches the recipient's public key.
-- **`change`**: An optional boolean flag indicating if the output is sending change back to the sender.
-
-We will now add an R-puzzle output to a transaction, making use of the script template.
-
-#### Example: Adding an Output
-
-```typescript
-// We must first obtain an R-value for the template
-const pubkey = PublicKey.fromString('...')
-pubkey.x.umod(c.n).toArray()
-r = r[0] > 127 ? [0, ...r] : r
-const puz = new RPuzzle()
-const lockingScript = puz.lock(r)
-
-let txOutput = {
-    satoshis: 1000, // Amount in satoshis
-    lockingScript,
-    change: false // Not a change output, it has a defined number of satoshis
-}
-
-myTx.addOutput(txOutput)
-```
-
-## Change and Fee Computation
-
-The transaction fee is the difference between the total inputs and total outputs of a transaction. Miners collect these fees as a reward for including transactions in a block. The amount of the fee paid will determine the quality of service provided my miners, subject to their policies.
-
-If the total value of the inputs exceeds the total value you wish to send (plus the transaction fee), the excess amount is returned to you as "change." Change is sent back to a destination controlled by the sender, ensuring that no value is lost. When you set the `change` property on an output to `true`, you don't need to define a number of satoshis. This is because the library computes the number of satoshis for you, when the `.fee()` method is called.
-
-In summary:
-
-1. After all funding sources and recipient outputs are added, add at least one output where `change` is `true`, so that you capture what's left over after you send. Set up a locking script you control so that you can later spend your change.
-
-2. Then, call the `.fee()` method to compute the change amounts across all change outputs, and leave the rest to the miner. You can specify a custom fee model if you wish, but the default should suffice for most use-cases.
-
-In our above code, we already added a change output — now, we can just compute the fees before transaction signing.
-
-```typescript
-// Compute the correct amounts for change outputs and leave the rest for the Bitcoin miners
-myTx.fee()
-```
-
-## Signing and Signature Validity
-
-Once you've defined your inputs and outputs, and once your change has been computed, the next step is to sign your transaction. There are a few things you should note when signing:
-
-- Only inputs with an unlocking template will be signed. If you provided an unlocking script yourself, the library assumes the signatures are already in place.
-- If you change the inputs or outputs after signing, certain signatures will need to be re-computd, depending on the SIGHASH flags used.
-- If your templates support it, you can produce partial signatures before serializing and sending to other parties. This is especially useful for multi-signature use-cases.
-
-With these considerations in mind, we can now sign our transaction. The `RPuzzle` unlocking templates we configured earlier will be used in this process.
-
-```typescript
-// Set the input unlocking scripts based on the script templates
-myTx.sign()
-```
-
-## Serialization and Broadcast
-
-After a transaction is signed, it can be broadcast to the BSV Mining Network, or to relevant Overlay Networks through the SDK.
-
-```typescript
-await tx.broadcast()
-```
-
-Alternatively, if you don't want to use the SDK's built-in broadcasting system, you can simply serialize your transaction into a hex string as follows:
-
-```typescript
-// Serialize your transaction
-myTx.toHex()
-```
-
-## SPV and Serialization Formats
-
-Simplified Payment Verification is a mechanism that enables the recipient of a transaction to verify its legitimacy by providing necessary information, like input transactions and their associated merkle proofs.
-
-Earlier in this guide, we mentioned that you can either reference a `sourceTXID` or, preferably, a `sourceTransaction` when linking transaction inputs. The reason why it's preferable to link the entire source transaction is because serializing the transaction in an SPV-compliant way generally requires more information about the outputs being spent.
-
-When properly linked, you can serialize your transactions in the SPV formats as follows:
-
-```typescript
-// Note: Requires use of sourceTransaction instead of sourceTXID for inputs
-myTx.toHexBEEF()
-// or
-myTx.toHexEF()
-```
-
-This enables the transactions to be verified properly by recipients, using the `.verify()` method:
-
-```typescript
-const incomingTX = Transaction.fromHexBEEF('...')
-incomingTX.verify() // Provide a source of BSV block headers to verify
-```
-
-Recipients, with nothing other than a source of BSV block headers, can verify that the transaction properly unlocks and redeems its inputs, thereby creating its outputs. To learn more about setting up a chain tracker with a source of block headers, check out the Pulse example (link to be provided once completed).

package/docs/examples/EXAMPLE_ECIES.md

@@ -1,37 +0,0 @@
-# Example: Using ECIES Encryption
-
-Electrum ECIES is a protocol for exchanging encrypted data between parties. It has been commonly used in many applications, and while the SDK's native [Message Encryption functionality](EXAMPLE_ENCRYPT_DECRYPT_MESSAGE.md) is the preferred approach for new applications (due to its use of GCM over CBC and aditional layers of security described below), legacy systems still use ECIES and this guide will demonstrate how it can be done.
-
-## Message Encryption
-
-In ECIES, a message can be encrypted directly to the public key of the recipient, either from your private key or from a random private key. The public key can either be included or excluded from the message. Check out the below examples:
-
-```typescript
-import { ECIES, PrivateKey, Utils } from '@bsv/sdk'
-
-const alicePrivateKey = PrivateKey.fromString('77e06abc52bf065cb5164c5deca839d0276911991a2730be4d8d0a0307de7ceb', 16)
-const bobPrivateKey = PrivateKey.fromString('2b57c7c5e408ce927eef5e2efb49cfdadde77961d342daa72284bb3d6590862d', 16)
-const message = Utils.toArray('this is my ECDH test message', 'utf8')
-
-const ecdhMessageEncryptedAlice = ECIES.electrumEncrypt(message, alicePrivateKey.toPublicKey(), bobPrivateKey, true)
-console.log(Utils.toUTF8(ECIES.electrumDecrypt(ecdhMessageEncryptedAlice, bobPrivateKey, alicePrivateKey.toPublicKey())))
-// 'this is my ECDH test message'
-
-const ecdhMessageEncryptedBob = ECIES.electrumEncrypt(message, bobPrivateKey.toPublicKey(), alicePrivateKey, true)
-console.log(Utils.toUTF8(ECIES.electrumDecrypt(ecdhMessageEncryptedBob, alicePrivateKey, bobPrivateKey.toPublicKey())))
-// 'this is my ECDH test message'
-```
-
-Here, we start by declaring two private keys. Then, ...
-
-## Considerations
-
-This guide has shown how to use Electrum ECIES encryption. While this approach has been used by many legacy systems, the SDK's native encryption has the following benefits:
-
-- **Additional Security Layer**: The native SDK implentation, based on [BRC-78](https://github.com/bitcoin-sv/BRCs/blob/master/peer-to-peer/0078.md), employs an additional layer of security by utilizing a one-off ephemeral key for the encryption process. Even if the key for a particular message is discovered, it does not compromise the private keys of either of the parties. Different keys are used for every message, adding an additional step for attackers.
-
-- **Incompatibility with BRC-43 Invoice Numbers**: The native approach is fully compatible with [BRC-43](https://brc.dev/43) invoice numbers, and the [BRC-2](https://brc.dev/2) encryption process, making it possible for users of the [BRC-56 standard wallet](https://brc.dev/56) able to natively use the system under their MetaNet identities. ECIES is not compatible with these standards.
-
-- **Use of GCM over CBC**: While this is not a security risk, GCM supports range-based encryption and decryption. This may make it better than CBC if you need to send parts of a large encrypted dataset over the network.
-
-Despite these drawbacks, Electrum ECIES still remains a fundamentally secure and robust encryption scheme.

package/docs/examples/EXAMPLE_ENCRYPT_DECRYPT_MESSAGE.md

@@ -1,52 +0,0 @@
-# Example: Message Encryption and Decryption
-
-This guide walks you through the steps of encrypting and decrypting messages.
-
-## Overview
-
-Understanding the ins-and-outs of message encryption and decryption is key to implementing secure communication. The implemented functions allow a sender to encrypt messages that only the intended recipient can decrypt, thus preserving the privacy of the message exchange.
-
-### Encrypting a Message
- To get started, you will first want to import the required functions / classes.
-
-```ts
-import { PrivateKey, EncryptedMessage, Utils } from '@bsv/sdk'
-```
-
-Next, you will want to configure who the sender is, the recipient, and what message you would like to encrypt.
-
-```ts
-const sender = new PrivateKey(15)
-const recipient = new PrivateKey(21)
-const recipientPub = recipient.toPublicKey()
-const message: number[] = Utils.toArray('Did you receive the Bitcoin payment?', 'utf8')
-```
-
-Now you are ready to generate the ciphertext using the `encrypt` function. This function will return an array of bytes so you will need to convert it using `toUTF` if you would like it as a string of text. 
-
-```ts
-const encrypted: number[] = EncryptedMessage.encrypt(message, sender, recipientPub)
-const ciphertextMessage: string = Utils.toUTF8(encrypted)
-```
-
-### Decrypting a Message
-
-To get back your plaintext message, use the `decrypt` function and then transform it as needed.
-
-```ts
-const decrypted: number[] = EncryptedMessage.decrypt(encrypted, recipient)
-const plaintextMessage: string = Utils.toUTF8(decrypted)
-// console.log(plaintextMessage) -> 'Did you receive the Bitcoin payment?'
-```
-
-## Considerations
-
-As you leverage encryption and decryption in your applications, it's crucial to remember:
-
-- **Key management**: Private keys should always be kept safe and never exposed. This library insures that intermediate keys generated for message encryption always use random nonces to mitigate key-reuse attack vectors. 
-
-- **Key of recipient:** The decryption stage using the recipient's key is always done on the recipient's end. As such, the recipient key used is the public key provided by the recipient, and is just generated in the above example for testing purposes.
-
-- **Interpretation of decrypted data**: The decrypted byte array may need to be transformed back into a string, depending on the nature of the original message. There are several utility functions exported, such as toUTF8, that can be leveraged as needed.
-
-This is just a simple example of how encryption and decryption can be implemented for secure message exchange in your applications. The exact method of implementation might vary based on your application’s specifics.

package/docs/examples/EXAMPLE_FEE_MODELING.md

@@ -1,199 +0,0 @@
-# Example: Creating a Custom Transaction Fee Model
-
-Bitcoin miners accept transactions into a block when they pay an appropriate fee. The transaction fee is simply the difference between the amounts used as input, and the amounts claimed by transaction outputs. This is to say, any amount of Bitcoins that are unclaimed (left over) after all transaction outputs have been fulfilled is given to the miner who solves the block in which the transaction is included.
-
-To date, fees have generally been measured in satoshis per kilobyte of block space used by the transaction. However, the SDK allows you to create custom fee models that take other factors into account. This guide will show you the default fee model, and discuss how it might be customized in the future. Note that you'll need to consult with various miners if considering an alternative fee model, to make sure your transactions would still be included in the blockchain.
-
-## Default Fee Model
-
-The `.fee()` method on a `Transaction` object takes a fee model as an optional parameter. The function of a fee model is to compute the number of satoshis that the transaction should pay in fees. Here's the interface all fee models need to follow:
-
-```typescript
-/**
- * Represents the interface for a transaction fee model.
- * This interface defines a standard method for computing a fee when given a transaction.
- *
- * @interface
- * @property {function} computeFee - A function that takes a Transaction object and returns a BigNumber representing the number of satoshis the transaction should cost.
- */
-export default interface FeeModel {
-  computeFee: (transaction: Transaction) => Promise<number>
-}
-
-```
-
-In short, a fee model is an object with a `computeFee` function that, when called with a `Transaction` as its first and only parameter, will return a `Promise` for a `number` of satoshis.
-
-The default fee model, used if no other model is provided, looks like this:
-
-```typescript
-/**
- * Represents the "satoshis per kilobyte" transaction fee model.
- */
-export default class SatoshisPerKilobyte implements FeeModel {
-  /**
-   * @property
-   * Denotes the number of satoshis paid per kilobyte of transaction size.
-   */
-  value: number
-
-  /**
-   * Constructs an instance of the sat/kb fee model.
-   *
-   * @param {number} value - The number of satoshis per kilobyte to charge as a fee.
-   */
-  constructor(value: number) {
-    this.value = value
-  }
-
-  /**
-   * Computes the fee for a given transaction.
-   *
-   * @param tx The transaction for which a fee is to be computed.
-   * @returns The fee in satoshis for the transaction, as a number.
-   */
-  async computeFee(tx: Transaction): Promise<number> {
-    const getVarIntSize = (i: number): number => {
-      if (i > 2 ** 32) {
-        return 9
-      } else if (i > 2 ** 16) {
-        return 5
-      } else if (i > 253) {
-        return 3
-      } else {
-        return 1
-      }
-    }
-    // Compute the (potentially estimated) size of the transaction
-    let size = 4 // version
-    size += getVarIntSize(tx.inputs.length) // number of inputs
-    for (let i = 0; i < tx.inputs.length; i++) {
-      const input = tx.inputs[i]
-      size += 40 // txid, output index, sequence number
-      let scriptLength: number
-      if (typeof input.unlockingScript === 'object') {
-        scriptLength = input.unlockingScript.toBinary().length
-      } else if (typeof input.unlockingScriptTemplate === 'object') {
-        scriptLength = await input.unlockingScriptTemplate.estimateLength(tx, i)
-      } else {
-        throw new Error('All inputs must have an unlocking script or an unlocking script template for sat/kb fee computation.')
-      }
-      size += getVarIntSize(scriptLength) // unlocking script length
-      size += scriptLength // unlocking script
-    }
-    size += getVarIntSize(tx.outputs.length) // number of outputs
-    for (const out of tx.outputs) {
-      size += 8 // satoshis
-      const length = out.lockingScript.toBinary().length
-      size += getVarIntSize(length) // script length
-      size += length // script
-    }
-    size += 4 // lock time
-    // We'll use Math.ceil to ensure the miners get the extra satoshi.
-    const fee = Math.ceil((size / 1000) * this.value)
-    return fee
-  }
-}
-```
-
-Here, you can see we're computing the size of the transaction in bytes, then computing the number of satoshis based on the number of kilobytes.
-
-## Making Adjustments
-
-Let's modify our fee model to check for a few custom cases, just as a purely theoretical example:
-
-- If the version of the transaction is 3301, the transaction is free.
-- If there are more than 3x as many inputs as there are outputs (the transaction is helping shrink the number of UTXOs), the transaction gets a 20% discount.
-- If there are more than 5x as many outputs as there are inputs, the transaction is 10% more expensive.
-- Other than that, the rules are the same as the Satoshis per Kilobyte fee model.
-
-With these rules in place, let's build a custom fee model!
-
-```typescript
-/**
- * Represents the "example" transaction fee model.
- */
-export default class Example implements FeeModel {
-  /**
-   * @property
-   * Denotes the base number of satoshis paid per kilobyte of transaction size.
-   */
-  value: number
-
-  /**
-   * Constructs an instance of the example fee model.
-   *
-   * @param {number} value - The base number of satoshis per kilobyte to charge as a fee.
-   */
-  constructor(value: number) {
-    this.value = value
-  }
-
-  /**
-   * Computes the fee for a given transaction.
-   *
-   * @param tx The transaction for which a fee is to be computed.
-   * @returns The fee in satoshis for the transaction, as a number.
-   */
-  async computeFee(tx: Transaction): Promise<number> {
-    const getVarIntSize = (i: number): number => {
-      if (i > 2 ** 32) {
-        return 9
-      } else if (i > 2 ** 16) {
-        return 5
-      } else if (i > 253) {
-        return 3
-      } else {
-        return 1
-      }
-    }
-
-    // Version 3301 transactions are free :)
-    if (tx.version === 3301) {
-        return 0
-    }
-
-    // Compute the (potentially estimated) size of the transaction
-    let size = 4 // version
-    size += getVarIntSize(tx.inputs.length) // number of inputs
-    for (let i = 0; i < tx.inputs.length; i++) {
-      const input = tx.inputs[i]
-      size += 40 // txid, output index, sequence number
-      let scriptLength: number
-      if (typeof input.unlockingScript === 'object') {
-        scriptLength = input.unlockingScript.toBinary().length
-      } else if (typeof input.unlockingScriptTemplate === 'object') {
-        scriptLength = await input.unlockingScriptTemplate.estimateLength(tx, i)
-      } else {
-        throw new Error('All inputs must have an unlocking script or an unlocking script template for sat/kb fee computation.')
-      }
-      size += getVarIntSize(scriptLength) // unlocking script length
-      size += scriptLength // unlocking script
-    }
-    size += getVarIntSize(tx.outputs.length) // number of outputs
-    for (const out of tx.outputs) {
-      size += 8 // satoshis
-      const length = out.lockingScript.toBinary().length
-      size += getVarIntSize(length) // script length
-      size += length // script
-    }
-    size += 4 // lock time
-    let fee = ((size / 1000) * this.value)
-
-    // Now we apply our input and output rules
-    // For the inputs incentive
-    if (tx.inputs.length / 3 >= tx.outputs.length) {
-        fee *= 0.8
-    }
-    // For the outputs penalty
-    if (tx.outputs.length / 5 >= tx.inputs.length) {
-        fee *= 1.1
-    }
-
-    // We'll use Math.ceil to ensure the miners get the extra satoshi.
-    return Math.ceil(fee)
-  }
-}
-```
-
-Now. when you create a new transaction and call the `.ee()` method with this fee model, it will follow the rules we have set above!

package/docs/examples/EXAMPLE_HD_WALLETS.md

@@ -1,71 +0,0 @@
-# Example: BIP32 Key Derivation with HD Wallets
-
-For a long time, BIP32 was the standard way to structure a Bitcoin wallet. While [type-42](EXAMPLE_TYPE_42.md) has since taken over as the standard approach due to its increased privacy and open-ended invoice numbering scheme, it's sometimes still necessary to interact with legacy systems using BIP32 key derivation.
-
-This guide will show you how to generate keys, derive child keys, and convert them to WIF and Bitcoin address formats. At the end, we'll compare BIP32 to the [type-42 system and encourage you to adopt the new approach](EXAMPLE_TYPE_42.md) to key management.
-
-## Generating BIP32 keys
-
-You can generate a BIP32 seed with the SDK as follows:
-
-```typescript
-import { HD } from '@bsv/sdk'
-const randomKey = HD.fromRandom()
-
-// Convert your "xprv" key to a string
-console.log(randomKey.toString())
-
-// Example: xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V
-```
-
-You can also import an existing key as follows:
-
-```typescript
-const importedKey = HD.fromString('xprv...')
-```
-
-Now that you've generated or imported your key, you're ready to derive child keys.
-
-## Deriving Child Keys
-
-BIP32 child keys can be derived from a key using the `.derive()` method. Here's a full example:
-
-```typescript
-const key = HD.fromString('xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V')
-const child = key.derive('m/0/1/2')
-console.log(child.toString())
-// 'xprv9yGx5dNDfq8pt1DJ9SFCK3gNFhjrL3kTqEj98oDs6xvfaUAUs3nyvVakQzwHAEMrc6gg1c3iaNCDubUruhX75gNHC7HAnFxHuxeiMVgLEqS'
-```
-
-Any of the standard derivation paths can be passed into the `.derive()` method.
-
-## Converting Between Formats
-
-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 = HD.fromString('xprv9s21ZrQH143K2vF2szsDFhrRehet4iHNCBPWprjymByU9mzN7n687qj3ULQ2YYXdNqFwhVSsKv9W9fM675whM9ATaYrmsLpykQSxMc6RN8V')
-
-// Convert XPRIV to XPUB
-const xpubKey = key.toPublic()
-console.log(xpubKey.toString());
-// xpub661MyMwAqRbcFQKVz2QDcqoACjVNUB1DZQK7dF9bKXWT2aKWfKQNfe3XKakZ1EnxeNP5E4MqZnZZw4P7179rPbeJEjhYbwF5ovkbGkeYPdF
-
-// Convert XPRIV to WIF
-console.log(key.privKey.toWif())
-// L1MZHeu2yMYRpDr45icTvjN7s3bBK1o7NgsRMkcfhzgRjLzewAhZ
-
-// Convert XPUB to public key
-console.log(xpubKey.pubKey.toString())
-// 022248d79bf217de60fa4afd4c7841e4f957b6459ed9a8c9c01b61e16cd4da3aae
-
-// Convert XPUB to address
-console.log(xpubKey.pubKey.toAddress())
-// 1CJXwGLb6GMCF46A721VYW59b21kkoRc5D
-```
-
-This guide has demonstrated how to use BIP32 for key derivation and format conversion. You can continue to use BIP32 within BSV wallet applications, but it's important to consider the disadvantages and risks of continued use, which are discussed below.
-
-## 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).

package/docs/examples/EXAMPLE_MESSAGE_SIGNING.md

@@ -1,63 +0,0 @@
-# Example: Message Signing
-
-This guide walks through the necessary steps for both public and private message signing.
-
-## Overview
-
-Message signing is a mechanism that preserves the integrity of secure communications, enabling entities to verify the authenticity of a message's origin. This document emphasizes two primary types of message signing: private and public.
-
-Private message signing is used when a message needs to be verified by a *specific recipient*. In this scenario, the sender creates a unique signature using their private key combined with the recipient's public key. The recipient, using their private key, can then verify the signature and thereby the message's authenticity.
-
-On the other hand, public message signing creates a signature that can be verified by *anyone*, without the need for any specific private key. This is achieved by the sender using only their private key to create the signature.
-
-The choice between private and public message signing hinges on the specific requirements of the communication. For applications that require secure communication where authentication is paramount, private message signing proves most effective. Conversely, when the authenticity of a message needs to be transparent to all parties, public message signing is the go-to approach. Understanding these differences will enable developers to apply the correct method of message signing depending on their specific use case.
-
-### 1. Example Code - Private Message Signing
- To get started, you will first want to import the required functions / classes.
-
-```ts
-import { PrivateKey, SignedMessage, Utils } from '@bsv/sdk'
-```
-
-Next, you will want to configure who the sender is, the recipient, and what message you would like to sign.
-
-```ts
-const sender = new PrivateKey(15)
-const recipient = new PrivateKey(21)
-const recipientPub = recipient.toPublicKey()
-const message: number[] = Utils.toArray('I like big blocks and I cannot lie', 'utf8')
-```
-
-Now we can sign the message and generate a signature that can only be verified by our specified recipient.
-
-```ts
-const signature = SignedMessage.sign(message, sender, recipientPub)
-const verified = SignedMessage.verify(message, signature, recipient)
-// console.log(verified) -> true
-```
-
-### 2. Example Code - Public Message Signing
-To create a signature that anyone can verify, the code is very similar to the first example, just without a specified recipient. This will allow anyone to verify the signature generated without requiring them to know a specific private key.
-
-```ts
-import { PrivateKey, SignedMessage, Utils } from '@bsv/sdk'
-
-const sender = new PrivateKey(15)
-const message: number[] = Utils.toArray('I like big blocks and I cannot lie', 'utf8')
-
-const signature = SignedMessage.sign(message, sender)
-const verified = SignedMessage.verify(message, signature)
-// console.log(verified) -> true
-```
-
-## Considerations
-
-While these private signing functions are built on industry standards and well-tested code, there are considerations to keep in mind when integrating them into your applications.
-
-- **Private Key Security**: Private keys must be stored securely to prevent unauthorized access, as they can be used to sign fraudulent messages.
-
-- **Use Case Analysis**: As stated in the overview, you should carefully evaluate whether you need a private or publicly verifiable signature based on your use case.
-
-- **Implications of Signature Verifiability**: When creating signatures that anyone can verify, consider the implications. While transparency is achieved, sensitive messages should only be verifiable by intended recipients.
-
-By understanding and applying these considerations, you can ensure a secure implementation of private signing within your applications.