@bsv/sdk 1.1.1 → 1.1.3

package/docs/concepts/HOW_TX.md

@@ -1,60 +0,0 @@
-# How are Transactions Built with Inputs and Outputs?
-
-Transactions are one of 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 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 allows referenced previous output to be spent.
-- **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 transfer the ownership of satoshi commodity tokens or colloquially, coins, so their new owner can use them 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

@@ -1,38 +0,0 @@
-# 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

@@ -1,14 +0,0 @@
-# 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

@@ -1,42 +0,0 @@
-# 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

@@ -1,34 +0,0 @@
-# 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

@@ -1,35 +0,0 @@
-# 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_BUILDING_CUSTOM_TX_BROADCASTER.md

@@ -1,91 +0,0 @@
-# Example: Building a Custom Transaction Broadcast Client
-
-This guide walks through the necessary steps for building a custom transaction broadcast client.
-
-## Overview
-
-⚠️ It's important to notice that SDK is already providing broadcaster implementation that communicates with TAAL's ARC instance. This example is for educational purposes only.
-
-A transaction broadcast client is a crucial component in any Bitcoin SV application, allowing it to communicate with the Bitcoin SV network. Implementing a transaction broadcaster can be accomplished using the clearly defined Broadcast interface.
-
-Our task will be to create a broadcaster that connects with the What's on Chain service. This broadcaster is particularly designed for browser applications and utilizes the standard Fetch API for HTTP communications with the relevant API endpoints.
-
-## Getting Started
-
-In order to build a compliant broadcast client, we first need to import the interfaces to implement.
-
-```ts
-import { Transaction, BroadcastResponse, BroadcastFailure, Broadcaster } from '@bsv/sdk'
-```
-
-Next, we create a new class that implements the Broadcaster interface which requires a broadcast function. 
-
-We will be implementing a What's on Chain (WOC) broadcaster that runs in a browser context and uses [window.fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) to send a POST request to the WOC broadcast API endpoint.
-
-```ts
-import { Transaction } from '@bsv/sdk'
-import type { Broadcaster } from '@bsv/sdk/src/transaction/Broadcaster'
-
-/**
- * Represents an WOC transaction broadcaster.
- */
-export default class WOC implements Broadcaster {
-  network: 'main' | 'test'
-  URL: string
-
-  /**
-   * Constructs an instance of the WOC broadcaster.
-   *
-   * @param {string} network - which network to use (testnet or mainnet)
-   */
-  constructor(network: 'main' | 'test') {
-    this.network = network
-    this.URL = `https://api.whatsonchain.com/v1/bsv/${network}/tx/raw`
-  }
-
-  /**
-   * Broadcasts a transaction via WOC.
-   * This method will assume that window.fetch is available
-   *
-   * @param {Transaction} tx - The transaction to be broadcasted.
-   * @returns {Promise<BroadcastResponse | BroadcastFailure>} A promise that resolves to either a success or failure response.
-   */
-  async broadcast(tx: Transaction): Promise<BroadcastResponse | BroadcastFailure> {
-    const txhex = tx.toHex()
-
-    const requestOptions = {
-      method: 'POST',
-      headers: {
-        'Content-Type': 'application/json'
-      },
-      body: JSON.stringify({ txhex })
-    }
-
-    try {
-      let data: any = {}
-
-      // Use fetch in a browser environment
-      const response = await window.fetch(`${this.URL}`, requestOptions)
-      data = await response.json()
-
-      if (data.txid as boolean || response.ok as boolean || response.status === 200) {
-        return {
-          status: 'success',
-          txid: data?.txid,
-          message: data?.messages
-        }
-      }
-    } catch (e) {
-      // TODO: Implement error handling as needed
-    }
-  }
-}
-```
-
-Now, you can make use of this broadcast client when sending transactions with the `.broadcast()` method:
-
-```typescript
-await exampleTX.broadcast(new WOC('main'))
-```
-
-The result will be one of the SDK's standard `BroadcastResponse` or `BroadcastFailure` types, indicating the status of your transaction.

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.