diff --git a/courses/csv404/assets/en/001.webp b/courses/csv404/assets/en/001.webp new file mode 100644 index 00000000000..5c8d2955f6f Binary files /dev/null and b/courses/csv404/assets/en/001.webp differ diff --git a/courses/csv404/assets/en/002.webp b/courses/csv404/assets/en/002.webp new file mode 100644 index 00000000000..0b8e8153ab8 Binary files /dev/null and b/courses/csv404/assets/en/002.webp differ diff --git a/courses/csv404/assets/en/003.webp b/courses/csv404/assets/en/003.webp new file mode 100644 index 00000000000..646553bde76 Binary files /dev/null and b/courses/csv404/assets/en/003.webp differ diff --git a/courses/csv404/assets/en/004.webp b/courses/csv404/assets/en/004.webp new file mode 100644 index 00000000000..8335f2d1dd5 Binary files /dev/null and b/courses/csv404/assets/en/004.webp differ diff --git a/courses/csv404/assets/en/005.webp b/courses/csv404/assets/en/005.webp new file mode 100644 index 00000000000..7e46309d9b8 Binary files /dev/null and b/courses/csv404/assets/en/005.webp differ diff --git a/courses/csv404/assets/en/006.webp b/courses/csv404/assets/en/006.webp new file mode 100644 index 00000000000..74ee0780659 Binary files /dev/null and b/courses/csv404/assets/en/006.webp differ diff --git a/courses/csv404/assets/en/007.webp b/courses/csv404/assets/en/007.webp new file mode 100644 index 00000000000..0c7d86bc198 Binary files /dev/null and b/courses/csv404/assets/en/007.webp differ diff --git a/courses/csv404/assets/en/008.webp b/courses/csv404/assets/en/008.webp new file mode 100644 index 00000000000..e9c447149f7 Binary files /dev/null and b/courses/csv404/assets/en/008.webp differ diff --git a/courses/csv404/assets/en/009.webp b/courses/csv404/assets/en/009.webp new file mode 100644 index 00000000000..99d93c8e9a2 Binary files /dev/null and b/courses/csv404/assets/en/009.webp differ diff --git a/courses/csv404/assets/en/010.webp b/courses/csv404/assets/en/010.webp new file mode 100644 index 00000000000..d931970a21e Binary files /dev/null and b/courses/csv404/assets/en/010.webp differ diff --git a/courses/csv404/assets/en/011.webp b/courses/csv404/assets/en/011.webp new file mode 100644 index 00000000000..c895b8d47c5 Binary files /dev/null and b/courses/csv404/assets/en/011.webp differ diff --git a/courses/csv404/assets/en/012.webp b/courses/csv404/assets/en/012.webp new file mode 100644 index 00000000000..38cfebc97c0 Binary files /dev/null and b/courses/csv404/assets/en/012.webp differ diff --git a/courses/csv404/assets/en/013.webp b/courses/csv404/assets/en/013.webp new file mode 100644 index 00000000000..cf280ad5bcd Binary files /dev/null and b/courses/csv404/assets/en/013.webp differ diff --git a/courses/csv404/assets/en/014.webp b/courses/csv404/assets/en/014.webp new file mode 100644 index 00000000000..32e3ed797ec Binary files /dev/null and b/courses/csv404/assets/en/014.webp differ diff --git a/courses/csv404/assets/en/015.webp b/courses/csv404/assets/en/015.webp new file mode 100644 index 00000000000..5265e2c2213 Binary files /dev/null and b/courses/csv404/assets/en/015.webp differ diff --git a/courses/csv404/assets/en/016.webp b/courses/csv404/assets/en/016.webp new file mode 100644 index 00000000000..d1afab9a884 Binary files /dev/null and b/courses/csv404/assets/en/016.webp differ diff --git a/courses/csv404/assets/en/017.webp b/courses/csv404/assets/en/017.webp new file mode 100644 index 00000000000..64bf8f35a6b Binary files /dev/null and b/courses/csv404/assets/en/017.webp differ diff --git a/courses/csv404/assets/en/018.webp b/courses/csv404/assets/en/018.webp new file mode 100644 index 00000000000..2ec8d02e383 Binary files /dev/null and b/courses/csv404/assets/en/018.webp differ diff --git a/courses/csv404/assets/en/019.webp b/courses/csv404/assets/en/019.webp new file mode 100644 index 00000000000..e72da1f3414 Binary files /dev/null and b/courses/csv404/assets/en/019.webp differ diff --git a/courses/csv404/assets/en/020.webp b/courses/csv404/assets/en/020.webp new file mode 100644 index 00000000000..a41fa73a499 Binary files /dev/null and b/courses/csv404/assets/en/020.webp differ diff --git a/courses/csv404/assets/en/021.webp b/courses/csv404/assets/en/021.webp new file mode 100644 index 00000000000..9609cd6190f Binary files /dev/null and b/courses/csv404/assets/en/021.webp differ diff --git a/courses/csv404/assets/en/022.webp b/courses/csv404/assets/en/022.webp new file mode 100644 index 00000000000..023db97a407 Binary files /dev/null and b/courses/csv404/assets/en/022.webp differ diff --git a/courses/csv404/assets/en/023.webp b/courses/csv404/assets/en/023.webp new file mode 100644 index 00000000000..19491c849a7 Binary files /dev/null and b/courses/csv404/assets/en/023.webp differ diff --git a/courses/csv404/assets/en/024.webp b/courses/csv404/assets/en/024.webp new file mode 100644 index 00000000000..77045f44db8 Binary files /dev/null and b/courses/csv404/assets/en/024.webp differ diff --git a/courses/csv404/assets/en/025.webp b/courses/csv404/assets/en/025.webp new file mode 100644 index 00000000000..bad77ef4510 Binary files /dev/null and b/courses/csv404/assets/en/025.webp differ diff --git a/courses/csv404/course.yml b/courses/csv404/course.yml index ff2b93ba831..19edf743aad 100644 --- a/courses/csv404/course.yml +++ b/courses/csv404/course.yml @@ -155,67 +155,95 @@ tags: - technical-analysis videos: + # Part 2: Protocol Theory (5 videos) + - id: c8788ec8-780c-46ab-ac5c-9eb0dcd20590 + youtube: + - en: XFqOxxOcRHs + peertube: [] - id: f45eeea0-6583-498b-af6a-c148cbe0ed00 - youtube: [] + youtube: + - en: -yiTtO_p3Cw peertube: - en: fhfFF7SZJSdYqL4SdWYA8N + - id: 92add1f7-d1c7-4846-99e1-31d0b43fcc6e + youtube: + - en: a6Lxz1ycddg + peertube: [] - id: aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec - youtube: [] + youtube: + - en: xtklaJHfKIY peertube: - en: rQuTfJjASzq34tsan7VxV2 - id: 939fd065-61ec-42e0-9f19-543d7bb4f3fd - youtube: [] + youtube: + - en: 8Qi7VOvKe5o peertube: - en: dpLSZpcyGEYk79ejXn2eft + # Part 3: Installation (4 videos) - id: 70e894f7-3759-48fc-9fcb-a3a1b33a3214 - youtube: [] + youtube: + - en: Z7KLo-pGBJA peertube: - en: mA2x1KboohWJmXUDJ9SQZf - id: 30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b - youtube: [] + youtube: + - en: pYh-4EfdZaM peertube: - en: mcPAU6CfXJXLfXEcLxVMaG - id: c488fe53-5110-4e43-8b9c-7773d9969078 - youtube: [] + youtube: + - en: EaPZ3EbTWhE peertube: - en: eXQFEHkp4hEpdYnYnMvFZd - id: 42e7cc5c-18cf-47b0-9d42-879f14733cd5 - youtube: [] + youtube: + - en: o6U812eSE_Q peertube: - en: ocXrhEsZQa4oa5sCQsSPbZ + # Part 4: Asset Operations (6 videos) - id: 3bc078b4-183d-4970-b63e-66862a452566 - youtube: [] + youtube: + - en: FccI6j0mxuE peertube: - en: ityAbqrEZfPs93iawuDjoe - id: 89819d63-3011-4ac6-a1f7-66babd2134b8 - youtube: [] + youtube: + - en: IL4ojWyFPSk peertube: - en: cHgAkdbDVYk48cqXgcuxfj - id: 88cdc6ce-22f6-4ddd-90a3-da345a85eef1 - youtube: [] + youtube: + - en: o30AiqbsYhw peertube: - en: aTm6QdPxbyppfLeCjfbh85 - id: db1c8655-eb0b-49a1-83e8-dc0b16a35582 - youtube: [] + youtube: + - en: UEaNXu8me24 peertube: - en: 5vAeFUtoMWDQX8Qu7byGgh - id: a9a437a4-1664-4786-a4a8-6e78082abe59 - youtube: [] + youtube: + - en: qBTGxSHpyDo peertube: - en: v7pAUKB85wcMy6D57ueJjc - id: 03e4464a-7ce8-4fb1-889c-83f8a52ac315 - youtube: [] + youtube: + - en: hYUBA-AxrtE peertube: - en: jFzTjuZN22z35NNhNpcDHi + # Part 5: Advanced (3 videos) - id: df88fe13-4a2f-4251-82db-89ce07131947 - youtube: [] + youtube: + - en: 0nvkrWfxW3k peertube: - en: mQmPyo5Z1S832UWykk2hAm - id: 9b884ff3-fca1-4488-bdd9-bb1d27ed5af4 - youtube: [] + youtube: + - en: lopHP_nF0tE peertube: - en: mHZmJo6wBXojdbwU8dRnLV - id: 1694f29f-e009-4f0d-99d7-5cedb540c81a - youtube: [] + youtube: + - en: m0BSUqNZT_U peertube: - en: vxWLYZxxNTBYAsR5V16Ahz diff --git a/courses/csv404/cs.md b/courses/csv404/cs.md deleted file mode 100644 index 351684fe820..00000000000 --- a/courses/csv404/cs.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Poznámka: Videa k tomuto kurzu jsou dostupná pouze v angličtině. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/de.md b/courses/csv404/de.md deleted file mode 100644 index 1f54603b886..00000000000 --- a/courses/csv404/de.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Hinweis: Die Videos zu diesem Kurs sind nur auf Englisch verfügbar. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/en.md b/courses/csv404/en.md index dad1b1f1c80..b45c9c6a027 100644 --- a/courses/csv404/en.md +++ b/courses/csv404/en.md @@ -9,13 +9,9 @@ objectives: - Build and deploy Taproot Assets applications with advanced features --- -# Tapping into Taproot Assets +The Taproot Assets Protocol (TAP) enables the issuance, transfer, and management of arbitrary digital assets on Bitcoin, routable over the Lightning Network. This expert-level course takes you from the cryptographic data structures that make TAP possible through hands-on deployment and operation, covering everything from MerkleSum Sparse Merkle Trees and client-side validation to minting, sending, burning, and cross-asset Lightning payments via edge nodes and price oracles. -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. +Through 16 demonstration videos recorded by Hannah Rosenberg, a core contributor to the protocol at Lightning Labs, you will build and operate a complete Taproot Assets stack. Whether you are building stablecoins, collectibles, or custom financial instruments, this course provides the technical depth and practical skills to work with Taproot Assets in development and production environments. Note: The videos for this course are only available in English. @@ -27,132 +23,293 @@ Note: The videos for this course are only available in English. ## Course presentation a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. +### Welcome + +Bitcoin's base layer was designed to be a robust, minimalist settlement network, and for good reason. Yet the desire to issue and transfer diverse assets on top of this infrastructure has been present almost since Bitcoin's earliest days. With the activation of [Taproot](https://planb.academy/resources/glossary/taproot) (BIP 341) in November 2021, a new design space opened up, one that makes it possible to embed structured asset metadata directly inside Taproot outputs without bloating the blockchain or compromising privacy. **Taproot Assets** (formerly known as Taro) is the protocol that exploits this design space to its fullest, enabling the issuance, transfer, and management of arbitrary assets, from stablecoins to collectibles, anchored in Bitcoin's security model and routable over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network). + +This course is an expert-level, hands-on exploration of the Taproot Assets Protocol and its reference implementation, `tapd` (the Taproot Assets Daemon). It is built around 16 demonstration videos recorded by Hannah Rosenberg, a developer at Lightning Labs and a core contributor to the protocol itself. We will not remain at the surface of concepts: together, we will walk through the full lifecycle of a Taproot Asset, from the cryptographic data structures that make it possible, through installation and configuration of the tooling, all the way to minting, sending, burning, and routing assets over Lightning channels. If you are comfortable with Bitcoin transactions, have a working understanding of Taproot and the Lightning Network, and are not afraid of a terminal, this course was built for you. + +### What you will learn + +- **Understand the cryptographic foundations** of the Taproot Assets Protocol, including Merkle-Sum Sparse Merkle Trees (MS-SMT), client-side validation, and the proof system that secures asset ownership off-chain. +- **Install and configure `tapd`** from source, through the Polar development environment, and via the LitD integrated stack, so you can choose the setup that fits your workflow. +- **Mint new assets** using both the CLI and the gRPC/REST API, mastering the parameters that define an asset's properties at creation time. +- **Send and receive Taproot Assets** between nodes, generating and verifying the transfer proofs that replace on-chain visibility with cryptographic certainty. +- **Burn assets permanently**, removing them from circulation in a verifiable way through the protocol's native burn mechanism. +- **Federate and query universes**, the public repositories that allow nodes to discover assets and verify their provenance without trusting a central authority. +- **Explore advanced operational topics** including TAPD upgrades, asset routing over Lightning channels, edge node architecture, and price oracle integration. + +### Curriculum -**Section 1: Protocol Foundations** +This course is organized into four technical parts that follow a deliberate progression from theory to practice, and from foundational operations to advanced deployment scenarios. -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. +**Part 2: The Taproot Asset Protocol** lays the theoretical groundwork. We will examine the Merkle-Sum Sparse Merkle Tree structure, the proof and verification system, the role of universes as asset discovery layers, how Taproot Assets integrate with the Lightning Network, and the API architecture that ties everything together. This is where you build the mental model that makes every subsequent command make sense. -**Section 2: Installation and Configuration** +**Part 3: Installation and Configuration** moves us into the terminal. We will compile `tapd` from source, set up a complete development environment using Polar, deploy the LitD integrated stack for a more production-oriented workflow, and configure universe federation so your node can participate in the broader asset network. -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. +**Part 4: Asset Operations** is the heart of the hands-on work. We will mint assets, send them between nodes, and burn them, executing every operation through both the CLI and the API. By the end of this part, you will have performed the complete asset lifecycle with your own hands. -**Section 3: Operations and Development** +**Part 5: Advanced Topics** addresses the concerns that arise once basic operations are mastered. We will cover how to update TAPD safely, how Taproot Assets flow over Lightning payment channels, how edge nodes bridge the gap between on-chain and off-chain routing, and how price oracles provide the exchange rate data that real-world applications require. -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. +Please note that all demonstration videos in this course are in English. Let's begin. -**Section 4: Advanced Topics** +### About the course author and sources -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. +This course is built from two primary sources: Hannah Rosenberg's [Tapping into Taproot Assets video playlist](https://www.youtube.com/playlist?list=PL-3jjRT_28SjD1cBGuJSWhgtyErVlzRmP) published by Lightning Labs, and the [official Taproot Assets documentation](https://docs.lightning.engineering/the-lightning-network/taproot-assets). The written content you are reading has been structured and edited by Plan B Academy to follow our educational format, but the technical substance and all demonstration videos are Hannah's original work. -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. +Hannah Rosenberg is a software developer at Lightning Labs, where she works directly on the Taproot Assets Protocol and its reference daemon, `tapd`. As a core contributor to the protocol's design and implementation, she brings a rare perspective: not the perspective of someone who learned the tool after the fact, but of someone who helped build it and understands the reasoning behind each architectural decision. Her demonstrations move fluidly between high-level protocol concepts and the concrete CLI commands that bring them to life. -# The Taproot Asset Protocol +All video content remains the intellectual property of Lightning Labs and Hannah Rosenberg. The written course material is licensed under CC-BY-SA-V4 as part of the Plan B Academy open-source educational content. + +# The Taproot Asset Protocol d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 + +## The Multi-Asset Lightning Network +84aeb178-895e-4212-aba3-4c7a015d31e2 + +:::video id=c8788ec8-780c-46ab-ac5c-9eb0dcd20590::: + +### A Story of Cross-Asset Payments + +Before we dive into protocol mechanics, let's discover together what the Taproot Assets Protocol makes possible through a concrete scenario. + +Imagine a [Lightning Network](https://planb.academy/resources/glossary/lightning-network) with thousands of nodes connected via channels full of satoshis. Now imagine the edges of that network: channels that hold not just bitcoin, but various assets, from US dollar stablecoins to euro-denominated tokens. Assets can flow from one side of the network through all the satoshi liquidity in the middle, and out to a node at the other end. The intermediate channels carry ordinary Lightning payments; only the endpoints deal in Taproot Assets. + +Let's make this concrete. Alice lives in the United States and holds a **USD stablecoin** on the Lightning Network via Taproot Assets. She is traveling to Berlin for a conference and meets her friend Roberto from Mexico, who holds a **peso-based stablecoin**. After lunch together, Alice pays the bill using her USD stablecoin, but the restaurant, being in Berlin, opts to receive the payment in a **euro-based stablecoin**. Roberto then pays Alice back for his half, sending pesos, while Alice chooses to receive the repayment in satoshis. + +All of these cross-asset transactions are routed seamlessly through the satoshi channels in the middle of the Lightning Network. While this exact story is fiction, all of the technology to make it happen is real and running on mainnet today. + +### How TAP Makes This Possible + +The **Taproot Assets Protocol (TAP)** is opt-in, uses client-side validation, requires no consensus changes to Bitcoin, and is available on mainnet. Assets are embedded in [Taproot](https://planb.academy/resources/glossary/taproot) transactions, so even minting does not require high fees. + +When Alice wants to mint a fungible asset (let's call it "beefbucks"), she specifies the supply, sets the asset type to fungible, and adds any metadata she wants to include. The **Taproot Assets Daemon (TAPD)** then constructs a set of specialized Merkle trees called **Merkle Sum Sparse Merkle Trees** to store all of this data. We will explore these data structures in detail in the next chapter. + +To commit this data to the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain), TAPD sums the collection of Merkle trees to a root hash, adds that root hash to the Bitcoin script tree, and embeds everything into a Bitcoin address using **TAPTweak**. To anyone looking at the blockchain, the minting transaction appears to be just a regular Taproot transaction. No one can tell that asset data was embedded unless they possess the cryptographic proofs. This is what we mean by **client-side validation**. + +### On-Chain Transfers + +When Alice wants to send 100 of her 1,000 beefbucks to Bob, their TAPD nodes take the current Merkle tree (where Alice holds 1,000 beefbucks) and construct two new Merkle trees: one where Alice holds 900 and another where Bob holds 100. Alice uses her asset-bearing [UTXO](https://planb.academy/resources/glossary/utxo) as an input to a transaction with at least two outputs: one for her updated tree and one for Bob's new tree. + +The protocol also supports **internal transactions**, where assets move between leaves within the same set of Merkle trees. This still requires an on-chain transaction to commit the updated state, but it opens up interesting use cases. + +### Lightning Channels with Assets + +If Alice holds a UTXO with assets and wants to open a Lightning channel with Bob, she can use that asset-bearing UTXO as the channel funding input. The resulting channel holds both satoshis and Taproot Assets. Once open, Alice and Bob can send assets back and forth, updating the asset balance in the channel. On-chain, this looks like opening any other Taproot channel. + +### The Edge Node + +The final piece of the multi-asset Lightning puzzle is the **edge node**. An edge node operates at the boundary between asset channels and satoshi channels. + +Let's say Alice runs a wallet service with an edge node. Her customers (Bob, Carol, Diego) all hold USD stablecoin channels with her edge node. The edge node also has regular satoshi channels connecting it to the broader Lightning Network. On the other side of the network, Elena and Frank are connected to a different edge node that supports a euro stablecoin. + +When Bob wants to pay Elena, Alice's edge node calculates how many stablecoin units Bob needs to send, then forwards the payment as a regular satoshi-based Lightning payment. That payment routes through the network until it reaches Elena's edge node, which converts the satoshis to euro stablecoins and updates its channel balance with Elena. + +In other words, Bob sent USD stablecoins and Elena received euro stablecoins, with the Lightning Network's satoshi liquidity bridging the gap transparently. After the initial coordination between Taproot Assets nodes, the payment routes just like any other Lightning payment, with all the same liquidity, speed, and security guarantees. + ## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 :::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: -### Understanding Taproot Asset +### Understanding Taproot Assets + +The **Taproot Assets Protocol (TAP)**, originally known as the Taproot Asset Representation Overlay (Taro), introduces a method for issuing arbitrary assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain) using the capabilities of [Taproot](https://planb.academy/resources/glossary/taproot). What makes TAP especially compelling is that these assets can also be transferred over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and low cost of Lightning payments. + +Because TAP is fundamentally built on Taproot, understanding the protocol requires a working knowledge of Taproot's mechanics. This is not merely a technical convenience: Taproot is the very foundation that makes TAP's approach to asset representation possible. + +Let's examine the core idea. A Taproot asset can be thought of as a specialized [UTXO](https://planb.academy/resources/glossary/utxo) nested inside a standard Bitcoin Taproot UTXO. In other words, asset data is embedded within a regular Taproot transaction in a way that makes it indistinguishable from any other Taproot transaction to outside observers. Creating one or many assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be produced within it. + +Every asset created through this protocol receives a unique identifier, the **Asset ID**, computed as follows: + +$$\text{asset\_id} = \text{sha256}(\text{genesis\_outpoint} \| \text{asset\_tag} \| \text{asset\_meta})$$ + +This formula anchors each asset to its creation point on the Bitcoin blockchain: the genesis outpoint (the specific transaction output where the asset was born), the asset tag (its name), and any associated metadata. + +### The MerkleSum Sparse Merkle Tree + +The cryptographic backbone of TAP is a data structure called the **MerkleSum Sparse Merkle Tree (MS-SMT)**. It combines two separate [Merkle tree](https://planb.academy/resources/glossary/merkle-tree) concepts into a single structure. Let's explore each one before seeing how they fit together. + +The first component is the **Sparse Merkle Tree**. When spending a Taproot asset, the protocol must not only prove that an asset exists in the tree (an inclusion proof), but also prove that assets have been properly removed when spent. In other words, it must demonstrate the *absence* of data, not just its presence. A Sparse Merkle Tree solves this elegantly: each object is stored at a leaf position determined by the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of its data. This deterministic placement means that any object defines its own route through the tree. If the expected leaf is empty, the object is provably absent. + +The second component is the **Merkle Sum Tree**. Here, each leaf carries a numeric value representing an asset quantity, and every internal node holds the sum of all values in its subtree. The root therefore contains the total of all assets in the entire structure. This summation property provides a powerful anti-inflation guarantee: by checking the root sum, a validator can confirm that no new units have been created out of thin air, without examining every individual leaf. + +The complete MS-SMT integrates with Bitcoin's Taproot mechanism through the **tap tweak**. The tree root is committed to a Taproot output using the formula: + +$$Q = P + H(P \| c) \cdot G$$ + +where $P$ is the internal public key, $c$ is the MS-SMT commitment, $H$ is a hash function, and $G$ is the generator point. This creates an unbreakable cryptographic link between the on-chain Bitcoin transaction and the off-chain asset data. + +### Client-Side Validation and Proof Chains + +TAP relies on **client-side validation**: recipients do not need the complete blockchain history to verify an asset's legitimacy. Instead, the recipient reconstructs a partial MS-SMT, tweaks the issuer's public key using the commitment, and verifies that the corresponding genesis transaction exists on-chain. + +Every asset transfer generates a cryptographic proof. These proofs form a **proof chain** that traces the asset's ownership history all the way back to its genesis output. If a UTXO is spent without a valid new MS-SMT commitment, the proof is invalidated. This is why each transaction can be independently audited against the original issuance. + +### Lightning Network Integration + +The integration of fungible Taproot assets with Lightning represents one of the protocol's most practical features. To send a TAP asset over Lightning, only the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels holding that specific asset. All intermediate nodes along the payment route simply forward ordinary satoshis, unaware that the endpoints are dealing in Taproot assets. Alice can route a USD-denominated asset through Bob, Carol, and several other hops before reaching Dan, with none of the intermediate channels needing TAP awareness. + +Beyond simple transfers, the Lightning integration supports **automatic asset exchange** through a mechanism called **RFQ (Request for Quote)**. A Lightning invoice denominated in Bitcoin can be paid using a Taproot asset, or vice versa, with the conversion handled seamlessly. This opens the door to cross-asset Lightning payments that feel natural to the user while leveraging the full sophistication of TAP under the hood. + +### The Universe System -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. +**Universe** services provide the off-chain infrastructure for asset discovery and proof distribution. They function similarly to Bitcoin block explorers, but for Taproot Asset data, which is stored locally by TAP clients rather than directly on the blockchain. Universes hold no protocol-level privileges: they are data stores that anyone can run. By keeping detailed transaction histories off-chain while anchoring cryptographic commitments on-chain, the protocol achieves scalability without sacrificing security. -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. +## Merkle Sum Sparse Merkle Trees +6b4ab386-9c4c-4a6c-a260-2cd589e1c9de -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. +:::video id=92add1f7-d1c7-4846-99e1-31d0b43fcc6e::: -### MerkleSum as cryptographic foundation +### Why This Data Structure? -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. +In the previous chapters, we mentioned that TAPD stores asset data in **Merkle Sum Sparse Merkle Trees**. Let's now explore together what this data structure actually is, why it was designed this way, and how it gets embedded into a Bitcoin transaction. This chapter is more conceptual than practical, but understanding these foundations will make every subsequent operation far more intuitive. -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. +When we mint an asset (let's say "beefbucks"), we need to be able to prove three things: -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. +1. **Ownership**: that we do indeed hold the asset. +2. **Non-inflation**: that we have not created more units than we declared. +3. **Transfer**: that when we send assets to Bob, we can prove we no longer own what we sent. -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. +The Merkle Sum Sparse Merkle Tree solves all three problems in a single, elegant structure. Let's break it into its two components. -### Lightning Network Integration and Asset Transfers +### The Sparse Part: Proving Inclusion and Exclusion -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. +Imagine a massive [Merkle tree](https://planb.academy/resources/glossary/merkle-tree) with a huge number of possible leaf positions. When TAPD creates an asset, it generates an **Asset ID**. The binary representation of that ID acts as a map: each bit (one or zero) tells you to go right or left as you descend from the root to a leaf. In other words, the Asset ID deterministically defines exactly where in the tree the asset data lives. -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. +This design has a powerful consequence. To prove that an asset exists in the tree, you provide the Merkle inclusion proof following the path defined by the Asset ID. To prove that an asset does *not* exist, you show that the expected leaf position is empty. The "sparse" nature of the tree (most leaves are empty, with null hashes) makes these absence proofs efficient. -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. +This solves problems one and three: we can prove we own an asset (inclusion proof) and we can prove we no longer own it after transfer (exclusion proof at the original position). -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. +![Sparse Merkle tree binary navigation showing root hash branching left and right based on 0 and 1 bits](assets/en/002.webp) +### The Sum Part: Preventing Inflation + +The "sum" component adds a numeric value to each leaf. If we mint 100 beefbucks, the leaf holding our asset data carries the value 100. Each internal node in the tree carries the sum of all values in its subtree. This means the root hash of the tree encodes the total quantity of all assets it contains. + +When we send 50 beefbucks to Bob, our tree updates: our leaf changes from 100 to 50, and the sums propagate all the way up to the root. If we tried to lie about our balance (claiming we still have 100 while also sending 50 to Bob), the Merkle proofs would be inconsistent. In other words, we cannot inflate the supply without invalidating our own proofs, effectively burning our assets in the process. + +### Layers of Trees: A Merkle Forest + +The complete data structure is not a single tree but rather a series of layers: + +1. **Asset level**: the bottom layer, where individual asset data (name, metadata, balances) is stored in leaves. +2. **Group level**: above the asset level, this layer groups fungible assets together. All beefbucks minted across different rounds share the same group, making them interchangeable. This layer is what enables features like multi-tranche minting. +3. **Bitcoin Taproot tree**: the standard Bitcoin script tree, into which the entire Merkle forest is committed. + +The layered structure also allows requiring [private key](https://planb.academy/resources/glossary/private-key) signatures at different levels, adding both security and flexibility in use cases. For example, a group key signature can authorize new minting rounds, while individual asset keys control transfers. + +![Diagram showing the three layers of the Merkle forest: Taproot tree in white, group level in orange, and asset level in blue](assets/en/003.webp) + +![Two-level Asset Tree showing TAP root hash with TAP leaves at top and Asset root hash with Asset leaves at bottom](assets/en/001.webp) + +### From Merkle Forest to Bitcoin Transaction + +How does all of this data actually end up on the Bitcoin blockchain? The process can be summarized in one word: **TAPTweak**. + +TAPD sums the entire Merkle forest up to a single root hash. That root hash is then embedded into a Bitcoin address using the taptweak mechanism we discussed earlier: + +$$Q = P + H(P \| c) \cdot G$$ + +The result is a standard-looking Bitcoin Taproot output. To anyone examining the blockchain, it appears as an ordinary transaction. Only parties who possess the asset proofs (the paths through the Merkle forest) can verify that assets are embedded within it. + +You can visualize Taproot Assets as living inside a Bitcoin UTXO. When minting, TAPD communicates with LND (which communicates with Bitcoin Core) to create a transaction whose output contains the entire embedded Merkle forest. The inputs are regular bitcoin UTXOs funding the transaction, and the output is a Taproot address that secretly holds your entire asset tree. + +![Bitcoin transaction diagram showing inputs flowing to a Taproot UTXO output that contains the embedded Merkle tree structure](assets/en/004.webp) ## Taproot Assets Demo e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 :::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: -### Introduction to Taproot Asset Client +### The TAPD Stack + +Now that we understand the protocol's theory, let's discover the software that implements it. The **Taproot Assets Protocol Daemon (TAPD)** is the reference implementation developed by Lightning Labs. It operates as a layer that sits between your application and LND, forming a three-tier architecture: -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. +| Layer | Role | +|-------|------| +| **Bitcoin Core** | Base layer: blockchain data and transaction broadcasting | +| **LND** | Lightning layer: channel management and private key custody | +| **TAPD** | Asset layer: Taproot tweak computation, asset tracking, proof management | -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. +This separation of concerns is deliberate. LND holds the private keys, while TAPD handles the Taproot Asset logic. Neither component oversteps its role, providing what we might call **segmented custody**. -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. +TAPD ships as two binaries: +- **`tapd`**: the daemon itself, listening on gRPC (port 10029) and REST (port 8089) +- **`tapcli`**: the command-line interface for interacting with `tapd` -### Installation and Configuration +### Prerequisites and Installation -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). +Before installing TAPD, you must have a working LND node connected to a Bitcoin backend. For installation from source, you will also need **Go version 1.18 or greater**. The installation process compiles the Go source and places both binaries in your system's Go path. -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. +For initial experimentation, I propose to use a **regtest network via [Polar](https://lightningpolar.com/)**. Polar provides a Docker-based sandbox environment where you can create local Lightning topologies and test TAP operations without risking real funds. This is the safest way to learn. -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. +When `tapd` starts for the first time, it creates a `.taro` directory (or `.tapd` in newer versions) in your home folder, containing its database and operational data. You can optionally create a configuration file (`tapd.conf`) in this directory, though all settings can also be passed as command-line arguments. -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. +Starting the daemon requires specifying the network type, the LND address and port, and the paths to two LND credential files: the admin macaroon (for authentication) and the TLS certificate (for encrypted communication). Once running, `tapd` listens on its default ports and is ready to receive commands. -### Asset Operations and Transfers +### Basic Asset Operations -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. +Let's walk through the fundamental operations you will perform with `tapcli`. -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. +**Minting** creates new assets. The command requires an asset type (typically `normal`), a name, and a supply. You can add the `--skip_batch` flag to process the mint immediately rather than batching multiple minting requests together. After minting, run `tapcli assets list` to verify that your new asset appears with its expected name, quantity, and metadata. -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. +![Terminal showing JSON universe data with three assets: DemoBux, tapsouvenir, and BitcoinIsForever with their root hashes](assets/en/005.webp) -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. +**Sending** assets requires coordination between sender and recipient. The recipient generates a TAP address by specifying the asset ID and the amount they wish to receive. An important detail: unlike standard Bitcoin addresses, **TAP addresses are unique to each specific asset and amount combination**. The sender then executes the transfer using `tapcli assets send --addr [ADDRESS]`. After on-chain confirmation, both parties can verify updated balances via `assets list`. -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. +For deeper exploration of all available commands and their parameters, the comprehensive documentation at [docs.lightning.engineering](https://docs.lightning.engineering/) remains the definitive reference. ## Tap into the Universe c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 :::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: -### Taproot Assets Version 0.2: Advanced Features and Implementation +### Version 0.2: Asset Groups and Multi-Asset Transactions + +Taproot Assets **version 0.2** introduces several important advances. The most notable is **asset group** functionality, which enables more flexible minting strategies. + +When you mint an asset with **emission enabled**, the asset becomes part of a group that can accommodate future minting rounds (or tranches). Each subsequent mint shares the same group ID, producing fungible units across multiple issuances. Conversely, when emission is **disabled** (the default), the asset's supply is permanently capped at the initial mint. This mechanism allows issuers to make credible, cryptographically enforced commitments about supply limitations. + +Another powerful feature is the ability to include **multiple asset types within a single Bitcoin transaction**. Rather than requiring a separate on-chain transaction for each asset operation, the protocol embeds multiple asset transfers within the same transaction outputs. This significantly reduces the on-chain footprint while preserving all security guarantees. -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. +### The Four API Services -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. +TAPD exposes its functionality through four distinct API services, each with a clear responsibility: -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. +| Service | Responsibility | +|---------|---------------| +| **AssetWalletService** | Wallet operations and asset holdings | +| **MintService** | Asset creation and batch management | +| **TaprootAssetService** | Core protocol operations: transfers, proof validation, address generation | +| **UniverseService** | Asset discovery, synchronization, and proof distribution | -### API Architecture and PSBT Coordination +These services are accessible via both gRPC (for high-throughput applications) and REST (for standard HTTP integration). The API documentation includes Python and JavaScript examples that demonstrate common workflows. -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. +### The Dual PSBT Architecture -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. +TAP makes sophisticated use of **Partially Signed Bitcoin Transactions ([PSBTs](https://planb.academy/resources/glossary/psbt))** to coordinate multi-party asset operations, but with an important twist: it introduces two distinct PSBT types. -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. +**Virtual PSBTs (vPSBTs)** extend the standard PSBT format with custom fields for asset-level coordination between TAPD nodes. They carry asset-specific data such as Merkle tree updates, proof information, and commitment details, all wrapped in the familiar PSBT structure. -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. +Once the asset-level coordination is complete, the parties create an **anchor PSBT**: a standard Bitcoin PSBT that produces the on-chain transaction containing the new asset commitments. In other words, the virtual PSBT handles *what happens to the assets*, while the anchor PSBT handles *what happens on the blockchain*. -### Universe Architecture and Proof Systems +This dual architecture is a significant advantage for developers, because existing Bitcoin transaction libraries can handle the anchor PSBT without modification, while the virtual PSBT layer adds the asset-specific coordination on top. -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. +### Universe Roles and Federation -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. +We briefly introduced universes in the first chapter. Let's now examine them more concretely. A universe can be understood as serving four simultaneous roles: -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. +1. **Virtual mempool**: tracking pending asset operations +2. **Explorer**: browsing asset history and metadata +3. **Proof repository**: storing and serving cryptographic proofs +4. **Transaction library**: cataloguing completed asset operations -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. +Running a universe requires no special setup. Any TAPD instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. +The **federation** concept extends this model to enable coordination between multiple universe servers. Each client defines its own federation, a set of trusted universe servers from which it accepts asset data and proofs. Federation members periodically synchronize, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy and data availability while letting users choose their preferred information sources. +The API provides practical endpoints for interacting with universes: querying proofs by asset identifier or group key, importing proofs into a local universe instance, and verifying asset ownership through the wallet API. These verification operations involve checking cryptographic signatures, validating Merkle tree structures, and confirming that referenced Bitcoin transactions exist on-chain. # Initial Installation and Configuration f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 @@ -161,132 +318,366 @@ The REST API provides practical access to universe functionality through standar a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 :::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: -### Installing TAPD: A Complete Setup Guide +### Prerequisites + +Before installing the **Taproot Assets Protocol Daemon** (TAPD), we need to ensure that three foundational components are already in place on our system: + +1. **Bitcoin Core** (`bitcoind`) must be installed and fully synchronized with the blockchain. For initial development and testing, working on testnet is the recommended approach. +2. **LND** (Lightning Network Daemon) must be version 0.17 or greater to support TAPD v0.3. If you plan to run the latest TAPD releases, LND v0.20+ is required. +3. **Go** version 1.21 or later must be installed, as earlier versions will cause compilation errors. + +These three services form the stack on which TAPD operates: Bitcoin Core provides the base layer, LND provides the Lightning layer, and TAPD manages the Taproot asset logic on top of both. In other words, TAPD never touches private keys directly; it delegates all signing to LND, which itself relies on Bitcoin Core for on-chain data. + +### Building from Source + +Let's now walk through the compilation process step by step. + +1. Clone the official repository: -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. +```bash +git clone https://github.com/lightninglabs/taproot-assets.git +``` -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. +2. Enter the directory and checkout the stable version you wish to install. Always use a tagged release rather than the development branch: -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. +```bash +cd taproot-assets +git checkout v0.3.0 +``` -### Step-by-Step Installation and Configuration +3. Compile and install the binaries: -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. +```bash +make install +``` -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. +This command handles dependency resolution and compilation automatically. It produces two binaries installed in your Go binary directory (typically `$HOME/go/bin/`): +- `tapd`, the main daemon; +- `tapcli`, the command-line interface for interacting with it. -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. +![Terminal showing go version check and git clone of the taproot-assets repository](assets/en/006.webp) -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. +### Configuration -### System Integration and Verification +TAPD needs to know how to reach LND and on which network to operate. While you can pass every parameter as a CLI flag at startup, creating a dedicated configuration file is far more maintainable. TAPD looks for its config in the `.tapd` directory under your home folder. -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. +1. Create the data directory: -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. +```bash +mkdir -p ~/.tapd +``` -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. +2. Create and edit the configuration file `~/.tapd/tapd.conf`. A minimal example for testnet: -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. +```ini +network=testnet +debuglevel=debug -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. +lnd.host=localhost:10009 +lnd.macaroonpath=~/.lnd/data/chain/bitcoin/testnet/admin.macaroon +lnd.tlspath=~/.lnd/tls.cert +``` + +The two security-critical paths here are the **TLS certificate** and the **macaroon file**. These provide the cryptographic credentials for authenticated, encrypted communication between TAPD and LND. If either path is incorrect, the daemon will refuse to start. + +By default, TAPD listens on two ports: +- **gRPC**: `10029` +- **REST**: `8089` + +### Systemd Integration for Production + +For production deployments, we want TAPD to start automatically, restart on failure, and launch only after LND is ready. A systemd service file achieves all three. + +Create `/etc/systemd/system/tapd.service`: + +```ini +[Unit] +Description=Taproot Assets Daemon +After=lnd.service +Requires=lnd.service + +[Service] +User=youruser +ExecStart=/home/youruser/go/bin/tapd +Restart=on-failure +RestartSec=10 + +[Install] +WantedBy=multi-user.target +``` + +Then enable and start the service: + +```bash +sudo systemctl enable tapd +sudo systemctl start tapd +``` + +The `After=lnd.service` directive ensures TAPD waits for LND to initialize first, preventing race conditions at boot. + +![Terminal showing tapd startup logs including TLS certificate generation, ChainPlanter, and FederationEnvoy](assets/en/007.webp) + +![Terminal showing lsof output with bitcoind, lnd, and tapd all listening on their respective ports](assets/en/008.webp) + +### Alternatives + +Compiling from source offers full control, but two other installation paths exist. Pre-built binaries are available from the Lightning Labs releases page, eliminating the need for a Go toolchain entirely. For an even more integrated approach, **Lightning Terminal (LitD)** bundles TAPD alongside LND and several other services into a single package. We will explore LitD in detail in chapter 3.3. ## Prototype with Polar d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 :::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: -### Setting Up TAPD with Polar Development Environment +### Why Polar? + +Before deploying TAPD on testnet or mainnet, it is wise to experiment in a fully local environment where mistakes cost nothing and block confirmations happen on demand. This is exactly what **Polar** provides. + +[Polar](https://lightningpolar.com/) is a Docker-based desktop application for Mac, Windows, and Linux that lets you spin up complete Bitcoin and Lightning Network topologies with a few clicks. It uses the same software that runs on mainnet (Bitcoin Core, LND, TAPD), so everything you learn in Polar translates directly to production. The only prerequisite is having **Docker** installed and running on your machine. + +![Polar application landing page showing the Create a Lightning Network button](assets/en/009.webp) -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. +### Setting Up the Network -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. +A functional TAPD development environment requires a minimum topology: -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. +1. At least **1 Bitcoin Core** backend node for blockchain operations. +2. At least **2 LND nodes**, since TAPD requires LND as its Lightning implementation, and testing transfers requires two distinct endpoints. +3. **1 TAPD node per LND node**, paired through Polar's drag-and-drop interface. -### Configuring Nodes and API Access +Once the network is created, the first startup may take several minutes as Docker downloads the container images. After that, subsequent launches are nearly instant. -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. +![Polar showing the full Tapd Demo network running with alice-tap, bob-tap, alice, bob, and backend1 nodes all connected](assets/en/010.webp) -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. +Two configuration steps are essential before you begin experimenting: -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. +1. **Enable auto-mining.** TAPD operations (minting, sending, burning) all require on-chain confirmations. Auto-mining ensures blocks are produced automatically so you do not have to trigger them manually each time. +2. **Fund your nodes.** Asset minting creates on-chain transactions that consume bitcoin. Polar provides built-in funding mechanisms that generate testnet balances for your nodes automatically. -### Asset Operations and Development Workflow +### Credentials and API Access -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. +Each node in Polar exposes connection details for both REST and gRPC access, including network addresses, port numbers, and authentication credentials. The system automatically generates the **TLS certificates** and **macaroon files** required for secure API communication. You will find these credentials in each node's detail panel within the Polar interface. -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. +### Testing Your First Mint -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. +With the network running and nodes funded, we can verify the setup by performing a basic mint operation. As we saw in Part 2, minting in TAPD involves two distinct phases: -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. +1. **Batch creation**: TAPD prepares all necessary data structures and cryptographic commitments, but does not yet write anything to the blockchain. +2. **Batch finalization**: the prepared asset data is embedded into a Bitcoin transaction and confirmed on-chain (handled automatically by auto-mining). + +After finalization and block confirmation, query your node's asset list to verify the mint succeeded. An empty result before minting and a populated result afterward confirms that your entire stack, from Bitcoin Core through LND to TAPD, is functioning correctly. + +Polar is an excellent sandbox for all the operations we will cover in Part 4 (minting, sending, burning) without risking real funds or waiting for real block times. + +![Polar alice-tap node showing Taproot Assets v0.3.0-alpha with zero assets on a fresh node](assets/en/011.webp) + +![Polar TAP Asset Info panel showing Alice Coin with Balance 100000 and Type NORMAL](assets/en/012.webp) ## Launch with Litd b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 :::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: -### Installing TAPD via Lightning Terminal from Source +### What LitD Bundles + +**Lightning Terminal** (LitD) is Lightning Labs' integrated daemon that bundles five services into a single binary: + +- **LND** for Lightning Network operations; +- **TAPD** for Taproot Assets; +- **Loop** for submarine swaps between on-chain and off-chain; +- **Pool** for Lightning channel liquidity marketplace; +- **Faraday** for channel analytics and recommendations. -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. +This integrated approach eliminates the complexity of managing separate installations and configurations for each service. Instead of five config files, five systemd units, and five sets of credentials, you manage one. This is why LitD is often the preferred path for users who want a complete Lightning and Taproot Assets stack without assembling each component individually. -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. +### Prerequisites and Installation -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. +Building LitD from source requires three tools: **Go**, **Node.js**, and **Yarn**. Ensure all three are installed before proceeding. -### Configuration and Wallet Setup +1. Clone the Lightning Terminal repository: -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. +```bash +git clone https://github.com/lightninglabs/lightning-terminal.git +``` -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. +2. Checkout the latest stable release: -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. +```bash +cd lightning-terminal +git checkout v0.13.0 +``` -### Service Integration and Verification +3. Compile everything: -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. +```bash +make install +``` -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. +This single command compiles LitD along with all bundled services (LND, TAPD, Loop, Pool, Faraday). The resulting binaries are placed in your Go path. -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. +### Configuration + +LitD reads its configuration from `~/.lit/lit.conf`. Create this directory and file: + +```bash +mkdir -p ~/.lit +``` + +A minimal `lit.conf` for testnet with a Bitcoin Core backend: + +```ini +network=testnet +lnd-mode=integrated + +bitcoind.rpchost=127.0.0.1 +bitcoind.rpcuser=yourrpcuser +bitcoind.rpcpass=yourrpcpassword +bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 +bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 +``` + +The `lnd-mode=integrated` setting tells LitD to manage LND internally rather than connecting to an external instance. + +![Terminal showing lit.conf configuration file in vim with lnd-mode integrated and bitcoin backend settings](assets/en/013.webp) + +As a lighter-weight alternative, you can use **Neutrino** instead of Bitcoin Core. Neutrino relies on compact block filters and does not require a full node, but this comes with trade-offs in privacy and verification guarantees. + +### Wallet Creation + +On first startup, LitD requires you to create a wallet through LND's CLI: + +```bash +lncli create +``` + +This command will generate a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for your wallet. Record it securely. This phrase can restore the wallet and all associated funds. + +For production environments, you can enable automatic wallet unlocking by storing the password in a secure file and referencing it in `lit.conf`: + +```ini +lnd.wallet-unlock-password-file=/path/to/password.txt +``` + +### Verification + +Once LitD is running, verify that all services are operational: + +```bash +litcli status +``` + +This command displays the state of every bundled service. You should see LND, TAPD, Loop, Pool, and Faraday all reporting as active. + +![Terminal showing litcli status output with all five services reporting as SERVER_ACTIVE](assets/en/014.webp) + +### Systemd for Production + +As with standalone TAPD, a systemd service ensures LitD starts at boot and restarts on failure. The key difference is the dependency: LitD depends on `bitcoind`, not on a separate LND service (since LND is bundled inside). + +```ini +[Unit] +Description=Lightning Terminal Daemon +After=bitcoind.service + +[Service] +User=youruser +ExecStart=/home/youruser/go/bin/litd +Restart=on-failure +RestartSec=10 + +[Install] +WantedBy=multi-user.target +``` ## Join a Universe Federation e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 :::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: -### Dicovering Universe Concepts +### What Is a Universe? + +In the Taproot Assets ecosystem, a **universe** is a data store that holds asset proofs and metadata. It functions like a block explorer, but specialized for Taproot Assets: it stores the off-chain proof data that TAP clients need to discover, verify, and transfer assets. You can think of it as a Git repository, but for asset proofs rather than code. -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. +Every TAPD node automatically includes its own local universe. When you mint an asset, the proof data is written to this local store. But the real power emerges when nodes connect their universes to share data with each other. This is what we call a **federation**: your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. +![Terminal showing the full tapd.conf configuration file with network, debug, and LND connection settings](assets/en/016.webp) -### Managing Universe Federations via CLI +### Managing Federations via CLI -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. +Let's discover together how to manage universe federations using the command line. -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. +**List your current federation:** -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. +```bash +tapcli universe federation list +``` -### API-Based Universe Management +A freshly started node typically shows at least one default universe that connects automatically at startup. -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. +**Add a new universe:** -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. +```bash +tapcli universe federation add --addr= +``` -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. +This is a user-controlled process. You choose which universes to connect to based on your specific needs. -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. +**Synchronize with your federation:** -### Practical Applications and Best Practices +```bash +tapcli universe sync +``` -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. +This pulls the latest asset data from all connected universes into your local store. -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. +![Terminal showing tapcli universe federation list with two servers and a universe sync command](assets/en/015.webp) -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. +**Discover available assets:** -# First Mints and Transactions +```bash +tapcli universe roots +``` + +This command reveals all assets your universe has discovered through its federation connections. + +**Remove a universe:** + +```bash +tapcli universe federation delete --addr= +``` + +### API-Based Federation Management + +For applications that need to manage federations programmatically, TAPD exposes full universe functionality through its REST API. + +**Add a universe via REST:** + +```bash +curl -X POST https://localhost:8089/v1/taproot-assets/universe/federation \ + --cacert ~/.tapd/tls.cert \ + --header "Grpc-Metadata-macaroon: $(xxd -ps -u -c 1000 ~/.tapd/data/testnet/admin.macaroon)" \ + -d '{"servers": [{"host": "universe.example.com", "id": 0}]}' +``` + +**Query federation statistics:** + +```bash +curl https://localhost:8089/v1/taproot-assets/universe/stats \ + --cacert ~/.tapd/tls.cert \ + --header "Grpc-Metadata-macaroon: $(xxd -ps -u -c 1000 ~/.tapd/data/testnet/admin.macaroon)" +``` + +The stats endpoint returns data about asset awareness, synchronization status, and federation health. + +![Terminal showing universe-stats output: 303 total assets, 26 groups, and 4737 proofs](assets/en/017.webp) + +### Best Practices + +I propose to close this chapter with a few operational guidelines for universe federation management: + +- **Curate rather than collect.** Connect to universes that serve your specific needs. Connecting to every available universe creates unnecessary network overhead. +- **Synchronize on a regular schedule.** Periodic `universe sync` calls ensure your local data stays current without excessive polling. +- **Review your federation periodically.** Remove inactive or irrelevant connections. +- **Use CLI for administration, API for automation.** Manual operations are best done through `tapcli`, while production workflows should use the REST or gRPC APIs. + +# Asset Operations c4d0776e-870b-11f0-86c9-8fee09142fba ## Mint from the CLI @@ -294,389 +685,648 @@ The combination of CLI and API access provides operational flexibility - CLI com :::video id=3bc078b4-183d-4970-b63e-66862a452566::: -### Transferring Taproot Assets via Command Line Interface +### Understanding the Minting Operation + +Now that our environment is properly configured, we can begin working with the core operations of the [Taproot](https://planb.academy/resources/glossary/taproot) Assets Protocol. The first of these operations is **minting**, which is the act of creating brand-new assets on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). Let's discover together how this process works from the command line. + +Minting a Taproot asset means embedding asset data into a Bitcoin Taproot transaction. When we mint, we define the fundamental properties of our new asset: its name, its total supply, and whether additional units can ever be created in the future. The result is a unique digital asset whose existence is anchored to Bitcoin's [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) security. In other words, minting is the genesis moment of an asset's life, the point where it begins to exist within the protocol. + +Before we can mint, our TAPD node must be running and properly connected to an LND node with confirmed on-chain funds. The minting transaction will consume a Bitcoin [UTXO](https://planb.academy/resources/glossary/utxo) to anchor the new asset data into the blockchain. -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. +### The Batch System -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. +An important concept to understand before minting is the **batch system**. By default, `tapcli` does not immediately broadcast a minting transaction when you issue a mint command. Instead, it places your minting request into a **batch**, a queue of pending asset creations that will all be finalized together in a single on-chain transaction. -### Node Configuration and Universe Federation +This design has a practical purpose. Since each minting transaction requires an on-chain Bitcoin transaction (and therefore a mining fee), batching allows you to create multiple distinct assets while paying only one transaction fee. -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. +The minting workflow therefore follows two phases: -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. +1. **Batch creation**: you add one or more asset definitions to the pending batch. +2. **Batch finalization**: you instruct TAPD to construct and broadcast the Bitcoin transaction that anchors all queued assets on-chain. -### Asset Transfer Workflow +If you prefer to skip batching and mint an asset immediately, you can append the `--skip_batch` flag. -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. +### Minting Your First Asset -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. +To create a new asset, we use the `tapcli assets mint` command: -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. +```bash +tapcli assets mint --type normal --name "MyToken" --supply 200 --skip_batch +``` -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. +Let's examine each parameter: -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. +- `--type normal`: specifies a **fungible** asset (as opposed to a collectible). +- `--name "MyToken"`: the human-readable name for our asset. +- `--supply 200`: the number of units to create. +- `--skip_batch`: finalize and broadcast immediately. -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. +![Terminal showing tapcli assets list returning empty then tapcli assets mint with CLIdemobux and BATCH_STATE_PENDING](assets/en/018.webp) -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. +To batch multiple assets instead, omit `--skip_batch` and finalize later with: -### Transfer Verification and Technical Considerations +```bash +tapcli assets mint finalize +``` -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. +![Terminal showing tapcli assets mint finalize with BATCH_STATE_BROADCAST and batch_txid](assets/en/019.webp) -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. +### Expandable Supply with Grouped Assets -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. +By default, once an asset is minted, its supply is fixed forever. However, the protocol provides a mechanism for assets that need expandable supply (for example, a stablecoin). -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. +This is achieved with the `--new_grouped_asset` flag (previously `--enable_emission`). When included during the initial mint, TAPD creates an **asset group** with a group key. Future minting operations can reference this group key to add new units: -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. +```bash +tapcli assets mint --type normal --name "ExpandableToken" --supply 1000 --new_grouped_asset --skip_batch +``` -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. +Assets minted within the same group share a common group identifier, making them fungible with one another even though they were created in separate events. + +![Terminal showing mint command with group_key flag to add units to an existing asset group](assets/en/020.webp) + +### Verification and the Genesis Outpoint + +After on-chain confirmation, verify your newly created assets: + +```bash +tapcli assets list +``` + +Each asset is identified by a unique **asset ID** derived from the [SHA-256](https://planb.academy/resources/glossary/sha256) hash of the genesis outpoint, the asset tag, and the asset metadata. The **genesis outpoint** is the Bitcoin transaction output that anchored the asset's creation, the unique fingerprint that allows any node to trace the asset back to its exact moment of birth. ## Mint from the API a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 :::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: -### Introduction to API-Based Asset Transfers +### Why Mint through the API? -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. +As we saw in the previous section, the CLI provides a direct and intuitive way to mint assets. However, for production environments or applications that need to create assets programmatically, the REST API offers a more flexible approach. Let's discover together how to perform the same minting operation through TAPD's API. -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. +The comprehensive API documentation is available at `lightning.engineering/api-docs/api/taproot-assets`, covering both gRPC and REST implementations with Python and JavaScript examples. -### Prerequisites and Configuration +### Prerequisites and Authentication -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. +Before making API calls, two security elements must be in place: -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. +1. **The TLS certificate**: ensures encrypted communication between your application and the TAPD node. +2. **The admin macaroon**: provides authentication and authorization for every API request. -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. +```python +import requests -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. +macaroon = open("/path/to/admin.macaroon", "rb").read().hex() +cert_path = "/path/to/tls.cert" +headers = {"Grpc-Metadata-macaroon": macaroon} +base_url = "https://your-node-ip:8089" +``` -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. +### Two-Phase Minting via the API -### API Operations and Transfer Workflow +**Phase 1: Add an asset to the batch.** -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. +```python +mint_payload = { + "asset": { + "asset_type": "NORMAL", + "name": "APIToken", + "amount": 500 + } +} -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. +response = requests.post( + f"{base_url}/v1/taproot-assets/assets/mint", + headers=headers, + json=mint_payload, + verify=cert_path +) +``` -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. +**Phase 2: Finalize the batch.** -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. +```python +finalize_response = requests.post( + f"{base_url}/v1/taproot-assets/assets/mint/finalize", + headers=headers, + json={}, + verify=cert_path +) +``` -### Best Practices for MINT through API +### Verification -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. +After on-chain confirmation, verify with a GET request: -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. +```python +assets = requests.get( + f"{base_url}/v1/taproot-assets/assets", + headers=headers, + verify=cert_path +) +``` -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. +In other words, while the CLI is ideal for manual exploration and one-off operations, the API is where Taproot Assets become a building block for larger systems. The security model remains identical: every request requires proper TLS and macaroon authentication. ## Send from the CLI d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 :::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: -### Transferring Taproot Assets via Command Line Interface +### Understanding Asset Transfers + +With our assets successfully minted, we can now explore the second fundamental operation: **sending** assets from one node to another. While minting creates new assets, sending transfers ownership of existing ones. Let's discover together how this works using the command line. -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. +Transferring a Taproot asset is fundamentally different from a simple Bitcoin payment. When we send bitcoin, the blockchain itself records the change of ownership. With Taproot Assets, the on-chain transaction commits to an updated [Merkle root](https://planb.academy/resources/glossary/merkle-root) that reflects the new ownership structure, but the detailed asset data is managed off-chain through **proof files** exchanged between the sender and receiver. -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. +### Universe Federation: A Prerequisite -### Node Configuration and Universe Federation +Before any transfer can take place, both the sender and the receiver must be part of a common **universe federation**. The receiver's node needs to know that the asset exists, what its genesis data looks like, and how to validate the incoming proofs. Without proper federation, the transfer will fail. -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. +### Step-by-Step Transfer Workflow -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. +Let's walk through a concrete example. Alice holds 100 tokens and wants to send 10 of them to Bob. -### Asset Transfer Workflow +**Step 1: Bob generates a receiving address.** -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. +```bash +tapcli addrs new --asset_id --amt 10 +``` -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. +The command produces an encoded **TAP address**, a long string that encodes the asset ID, the requested amount, Bob's destination key, and cryptographic data needed for the sender to construct a valid transfer. Unlike standard Bitcoin addresses, **TAP addresses are unique to each specific asset and amount combination**. -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. +**Step 2: Bob communicates the address to Alice.** -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. +This happens outside the TAPD protocol, through any communication channel the parties choose. -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. +**Step 3: Alice executes the send.** -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. +```bash +tapcli assets send --addr +``` -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. +Behind the scenes, Alice's node constructs an on-chain Bitcoin transaction that commits to the updated Merkle tree, generates cryptographic **proofs**, and transmits them directly to Bob's node. The command returns an on-chain transaction ID verifiable through any Bitcoin block explorer. -### Transfer Verification and Technical Considerations +**Step 4: Wait for on-chain confirmation.** -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. +The transfer is not complete until the Bitcoin transaction is confirmed in a block. -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. +**Step 5: Balance reconciliation.** -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. +After confirmation, both nodes update their balances automatically. Alice shows 90 tokens, Bob shows 10. -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. +![Terminal showing tapcli assets list with CLIdemobux balance of 100 and APIdemobux balance of 90 after transfers](assets/en/021.webp) -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. +### Reviewing Transfer History -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. +```bash +tapcli assets transfers +``` + +This provides a detailed record of every transfer, including transaction IDs, amounts, timestamps, and confirmation status. + +### Key Considerations + +- **Confirmation timing**: balance updates happen only after on-chain confirmation. +- **Proof transmission**: the proofs form the verifiable chain of custody back to the genesis output. +- **Universe synchronization**: if transfers fail, the most common cause is incomplete universe federation. ## Send from the API b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 :::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: -### Introduction to API-Based Asset Transfers +### Programmatic Asset Transfers + +As we saw in the previous section, sending Taproot Assets via the CLI follows a clear pattern. The REST API replicates this exact workflow through HTTP endpoints. Let's discover together how to implement this. -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. +### Three-Endpoint Workflow -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. +**Endpoint 1: Verify available assets (GET).** -### Prerequisites and Configuration +```python +assets = requests.get( + f"{base_url}/v1/taproot-assets/assets", + headers=headers, + verify=cert_path +) +``` -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. +**Endpoint 2: Generate a receiving address (POST).** -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. +```python +addr_payload = { + "asset_id": "", + "amt": 10 +} -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. +addr_response = requests.post( + f"{base_url}/v1/taproot-assets/addrs", + headers=headers, + json=addr_payload, + verify=cert_path +) +tap_address = addr_response.json()["encoded"] +``` -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. +**Endpoint 3: Execute the transfer (POST).** -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. +```python +send_payload = { + "tap_addrs": [tap_address] +} -### API Operations and Transfer Workflow +send_response = requests.post( + f"{base_url}/v1/taproot-assets/send", + headers=headers, + json=send_payload, + verify=cert_path +) +``` -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. +### Confirmation and Verification -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. +After submitting a transfer, the transaction must be confirmed on-chain before balances update. In other words, the API does not provide a push notification when a transfer confirms. Your application is responsible for monitoring the state. -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. +### Error Handling for Production -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. +When building transfer functionality into production applications, handle these scenarios: +- **Insufficient balance**: the send endpoint rejects requests if the node does not hold enough of the specified asset. +- **Invalid address**: malformed or expired TAP addresses produce an error response. +- **Missing universe data**: if the receiver's node lacks asset metadata, address generation will fail. ## Burn from the CLI e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 + :::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: -### Asset Burning via CLI +### Understanding Asset Burning -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. +The third and final core operation in the Taproot Assets lifecycle is **burning**, the permanent destruction of assets. While minting brings assets into existence and sending transfers them between parties, burning removes them from circulation forever. Let's discover together how this operation works from the command line. -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. +Why burn assets? A stablecoin issuer might burn tokens when users redeem them for fiat. A project might burn test tokens. An organization might reduce supply for governance reasons. In all cases, the key property is **irreversibility**: once burned and confirmed on-chain, assets cannot be recovered by any means. -### Prerequisites and Asset Inventory +### Checking Your Inventory -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. +Before any destructive operation, verify your current holdings: -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. +```bash +tapcli assets list +``` -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. +Carefully identify the exact asset you intend to burn and note its asset ID. A mistake here could result in burning the wrong asset. -### Executing the Burn Command +### Executing the Burn -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. +The burn command requires two parameters: -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. +```bash +tapcli assets burn --asset_id --amount 10 +``` -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. +TAPD presents an **interactive confirmation prompt** that explicitly warns about the permanent nature of the operation. You must confirm before the burn proceeds. -### Transaction Processing and Verification +For **automated environments**, the confirmation can be bypassed with a flag, but this should be treated with extreme caution. -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. +### Verification -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. +After on-chain confirmation: -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. +```bash +tapcli assets list +``` -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. +The balance should reflect the burned amount (e.g., 90 minus 10 = 80). In other words, treat every burn command as if it were a transaction sending funds to an address with no known private key, because functionally, that is exactly what it is. ## Burn from the API c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 :::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: -### Asset Burning via REST API +### Programmatic Asset Destruction -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. +The REST API implements an equivalent safety mechanism through a required confirmation parameter. Let's discover together how to burn assets programmatically. -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. +### Pre-Burn Inventory Check -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. +```python +assets = requests.get( + f"{base_url}/v1/taproot-assets/assets", + headers=headers, + verify=cert_path +) +``` -### Node Connection and Pre-Burn Setup +### Executing the Burn -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. +```python +burn_payload = { + "asset_id": "", + "amount": 5, + "confirmation_str": "assets will be destroyed" +} -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. +burn_response = requests.post( + f"{base_url}/v1/taproot-assets/burn", + headers=headers, + json=burn_payload, + verify=cert_path +) +``` -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. +The **confirmation string** is the API equivalent of the CLI's interactive prompt. Without it, the API rejects the burn request entirely. This forces the developer to explicitly acknowledge that assets will be permanently destroyed. -### Implementing the Burn Operation +### Post-Burn Verification -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. +After on-chain confirmation, query the assets endpoint again to confirm the reduced balance. For production systems, log every burn response in its entirety as an audit record. -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. +The burn operation completes the three fundamental lifecycle operations: creation through minting, movement through sending, and destruction through burning. -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. +# Diving deeper into Taproot Assets +863d9c88-870c-11f0-a2de-430d32152c27 -### On-Chain Confirmation and Verification +## Update Tapd +a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 +:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. +Keeping your **TAPD** node up to date is not optional. Each new release can patch security vulnerabilities, introduce protocol features required by the broader network, fix bugs that affect asset proofs or channel stability, and improve performance. The update procedure depends on how you installed TAPD in the first place. Whichever path you follow, one rule is absolute: **never delete your data directories** (`.tapd`, `.lnd`, `.bitcoin`) during an update. These folders contain your wallet, channel state, asset proofs, and blockchain data. The binaries are replaceable; the data is not. -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. +### Updating a Polar Installation -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. +If you set up your development environment with **Polar**, updating is handled mostly through the application's graphical interface. Open Polar and check whether new node versions are available in the settings panel. -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. +For major version jumps, Polar itself may need to be replaced: +1. Note down your current network topology so you can recreate it if needed. +2. Download the latest Polar release from [lightningpolar.com](https://lightningpolar.com). +3. Be aware that significant updates sometimes require you to **recreate your networks** from scratch. +4. Verify that TAPD nodes show the expected version in the node details panel. +### Updating a Binary Installation -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 +1. Stop the running TAPD service: -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: +```bash +sudo systemctl stop tapd +``` -### Introduction to TAPD Updates +2. Remove the old binaries: -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. +```bash +sudo rm /usr/local/bin/tapd /usr/local/bin/tapcli +``` -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. +3. Download the new release, verify the SHA256 checksum against the release notes: -### Updating Polar Installations +```bash +sha256sum taproot-assets-linux-amd64-v*.tar.gz +``` -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. +4. Extract and copy the new binaries: -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. +```bash +tar -xzf taproot-assets-linux-amd64-v*.tar.gz +sudo cp taproot-assets-linux-amd64-v*/tapd /usr/local/bin/ +sudo cp taproot-assets-linux-amd64-v*/tapcli /usr/local/bin/ +``` -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. +5. Restart and verify: -### Updating Binary Installations +```bash +sudo systemctl start tapd +tapcli version +``` -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. +### Updating a Source Installation -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. +1. Gracefully stop the daemon: -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. +```bash +tapcli stop +sudo systemctl stop tapd +``` -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. +2. Pull the latest changes and checkout the desired version: -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. +```bash +cd ~/taproot-assets +git fetch --all +git checkout v0.5.0 +``` -### Updating Source Installations +3. Compile and install: -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. +```bash +make install +``` -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. +4. Restart and verify: -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. +```bash +sudo systemctl start tapd +tapcli version +``` -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. +### Best Practices -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. +- **Use stable releases for production.** Release candidates are for testing only. +- **Back up before updating.** Copy `.tapd`, `.lnd`, and configuration files. +- **Read the release notes.** Some updates include breaking changes or migration steps. +- **Verify after every update.** A successful `tapcli version`, a healthy systemd status, and a quick `tapcli assets list` confirm everything is working. -### Best Practices and Considerations +## Building a Node from Scratch +992d8650-87f2-11f0-aace-9be7f0fb0b83 -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. +:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. +In the previous chapters, we installed TAPD as a standalone daemon alongside Bitcoin Core and LND. That approach works well, but it requires managing three separate services. In this chapter, we take a different path: building a complete node from scratch using **Lightning Terminal Daemon (LitD)**, a single binary that bundles LND, TAPD, Loop, Pool, and Faraday. -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. +The methodology presented here draws inspiration from Alex Bosworth's **Run LND** repository. The Lightning Labs team maintains a similar project called **Run LITD**, a collection of helper scripts, configuration templates, and systemd service files designed for rapid node deployment. -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 +An important caveat: the Run LITD scripts are built for **developers who need to spin up testing environments fast**. Never blindly execute automated scripts on a production server without reviewing every line. -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: +### Stage 1: Server Security + +The first script handles fundamental server hardening from a fresh Ubuntu installation: + +1. **Creates a non-root user** with `sudo` privileges. +2. **Configures SSH key-based authentication** (paste one or more public keys, one per line). +3. **Disables root login** over SSH. +4. **Disables password authentication.** + +Ensure your SSH keys are properly configured **before** running this script. If the script disables password authentication and your keys are not set up correctly, you will lock yourself out. + +### Stage 2: Bitcoin Core Installation + +The second stage installs and configures **Bitcoin Core** as the blockchain backend. Two installation approaches are available: + +- **Compilation from source** for maximum transparency. +- **Binary download with signature verification** for faster deployment. -### Introduction to Lightning Terminal Daemon (LITD) +The script then generates a secure **RPC credential string** for LND communication, prompts for **network selection** (mainnet, testnet, or signet), writes `bitcoin.conf`, and creates a systemd service. For development, **signet** is an excellent choice: it mimics mainnet behavior but uses worthless test coins. -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. +### Stage 3: LitD Installation -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. +The final stage installs the required dependencies (**Go**, **Node.js**, **Yarn**), then compiles LitD from source via `make install` (typically 5-10 minutes). After compilation: -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. +1. A `lit.conf` is generated using the RPC credentials from Stage 2. +2. A systemd service file is created, configured to start after Bitcoin Core. -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. +After dependency installation, **log out and reconnect** to ensure environment variables are loaded correctly. -### Three-Stage Setup Process +### Initial Startup and Wallet Creation -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. +LitD requires a wallet before it can operate: -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. +1. Start LitD manually in one terminal: -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. +```bash +litd +``` -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. +2. In a separate terminal, create the wallet: -### Practical Implementation Walkthrough +```bash +lncli create +``` -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. +3. Set a wallet password and record the **24-word seed phrase** securely. -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. +4. Configure automatic unlocking for production: -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. +```bash +echo "YourWalletPassword" > ~/.lit/wallet-password +chmod 600 ~/.lit/wallet-password +``` -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. +Add to `lit.conf`: -### Configuration and Initial Startup +```ini +lnd.wallet-unlock-password-file=/home/youruser/.lit/wallet-password +``` -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. +5. Stop the manual process and enable the systemd service: -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces +```bash +sudo systemctl enable litd +sudo systemctl start litd +``` + +### Verification + +Confirm everything is working: + +```bash +litcli status # All services running +lncli getinfo # LND synced to chain +tapcli assets list # TAPD responding (empty list expected) +tapcli universe federation list # Universe connectivity +sudo systemctl status litd # Systemd health +``` + +If all five checks pass, your node is fully operational. ## Running a Taproot Assets Price Oracle b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 :::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: -### Setting Up Price Oracles for Edge Networks +Up to this point, every Taproot Assets operation has stayed within a single asset type. But what happens when a payment needs to cross the boundary between two different assets, for example, when someone holding a stablecoin wants to pay a Lightning invoice denominated in bitcoin? + +This is where **edge nodes** and **price oracles** enter the picture. Together, they enable cross-asset payments on Lightning without requiring both parties to hold the same asset. + +### The Edge Node Concept + +An **edge node** is a Lightning node that maintains channels in at least two different asset types. Consider this scenario: + +- **Alice** has a Taproot Assets channel funded with a US dollar stablecoin. +- **Bob** has a standard Bitcoin Lightning channel. +- An **edge node** sits between them, holding both a stablecoin channel (connected to Alice) and a Bitcoin channel (connected to Bob). + +When Bob generates a Lightning invoice and sends it to Alice, she does not need to own any bitcoin. Alice sends stablecoins to the edge node, which converts them and forwards the corresponding bitcoin to Bob. In other words, the edge node acts as a bridge: it absorbs one asset on one side and releases another on the other side. + +### The Request for Quote (RFQ) System + +The critical question is: **how many stablecoin units must Alice send to cover Bob's bitcoin invoice?** + +The **RFQ (Request for Quote)** system answers this: -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. +1. Alice's node receives Bob's invoice and recognizes it needs bitcoin but only holds stablecoins. +2. Alice's node sends an RFQ request to the edge node. +3. The edge node consults its **price oracle** for the current exchange rate. +4. The edge node returns a quote with the exact stablecoin amount required. +5. Alice's node evaluates the quote and accepts or rejects it. -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. +This negotiation happens in milliseconds, transparently, before the payment is routed. -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. +### How the Price Oracle Works -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. +The **price oracle** calculates fair exchange rates. Key aspects: -### Technical Implementation and Configuration +- **External price feeds**: queries cryptocurrency exchanges or aggregators for current Bitcoin prices. For production, use multiple independent sources. +- **Asset registry**: explicitly lists supported assets by asset ID or group key. Group keys are especially useful for stablecoins with multiple minting rounds. +- **Decimal display**: defines how the smallest unit relates to the human-readable value. For a USD stablecoin, a decimal display of **6** means 1 dollar = 1,000,000 base units, enabling sub-cent precision. +- **Scaling factors**: additional internal precision during calculations to prevent floating-point rounding errors. -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. +### Building and Deploying the Oracle -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. +```bash +cd price-oracle +make build +sudo cp price-oracle /usr/local/bin/ +``` -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. +Create a systemd service for automatic management, then enable and start it. -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. +![Terminal showing price oracle log output with Bitcoin price at 107570 dollars and QueryAssetRates response](assets/en/022.webp) -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. +### Connecting the Oracle to Your Node -### Node Configuration and Practical Demonstration +A single configuration line in `lit.conf`: -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. +```ini +taproot-assets.experimental.rfq.priceoracleaddress=localhost:8095 +``` -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. +For a remote oracle, replace `localhost` with the server's IP address. -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. +![Terminal showing lit.conf with Taproot Assets experimental RFQ settings and price oracle address configuration](assets/en/023.webp) -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. +### Practical Demonstration -### Validation and Best Practices +With two **signet** nodes (one edge node with oracle, one client), the full RFQ workflow: -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. +**Creating an invoice with a group key:** -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. +```bash +litcli invoices addholdinvoice --amt_msat 50000000 --asset_group_key --rfq_peer_pubkey +``` -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. +**Paying the invoice:** -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. +```bash +litcli payinvoice +``` -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. +Behind the scenes, the RFQ negotiation happens automatically: quote request, oracle calculation, acceptance, stablecoin transfer, bitcoin forwarding. +![Terminal showing litcli addinvoice command creating an asset invoice with group_key and rfq_peer_pubkey parameters](assets/en/024.webp) + +### Verifying Oracle Accuracy + +- **Oracle logs**: show the exact Bitcoin price used, timestamps, and calculations. +- **Spreadsheet verification**: enter the reported price, asset amounts, and decimal display to independently calculate the expected conversion and compare with actual channel balance changes. + +### Production Considerations + +- **Multiple price feeds**: query at least two or three independent sources. +- **Asset support policies**: only support assets whose market dynamics you understand. +- **Comprehensive logging**: every quote, price fetch, and calculation should be logged. +- **Monitoring and alerting**: set up alerts for oracle downtime or price feed failures. + +The combination of edge nodes, the RFQ system, and price oracles creates a powerful infrastructure for multi-asset Lightning payments: Alice pays with stablecoins, Bob receives bitcoin, and the edge node facilitates the conversion at a market-determined rate, all within the speed and privacy guarantees of the Lightning Network. + +![Editor showing channel balance data with chan_id, local and remote balances, and asset group information after RFQ payment](assets/en/025.webp) # Final Section 9469342a-870c-11f0-88da-ff4cff486fe3 @@ -685,11 +1335,10 @@ The RFQ system's flexibility in supporting both individual asset IDs and group k 20570fc0-87e9-11f0-bdd0-cff9e0b16538 true +## Final Exam +a7f2c891-87e9-11f0-b3d4-2f8e9c4a6b15 +true + ## Conclusion 43393838-870d-11f0-b490-cb9bbebd87d5 true - - - - - diff --git a/courses/csv404/es.md b/courses/csv404/es.md deleted file mode 100644 index e163fecb506..00000000000 --- a/courses/csv404/es.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Nota: Los vídeos de este curso solo están disponibles en inglés. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/et.md b/courses/csv404/et.md deleted file mode 100644 index 15c83b97d7a..00000000000 --- a/courses/csv404/et.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Märkus: Selle kursuse videod on saadaval ainult inglise keeles. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/fa.md b/courses/csv404/fa.md deleted file mode 100644 index 7942134062b..00000000000 --- a/courses/csv404/fa.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -توجه: ویدیوهای این دوره فقط به زبان انگلیسی در دسترس هستند. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/fi.md b/courses/csv404/fi.md deleted file mode 100644 index 7eb3f5c9f1f..00000000000 --- a/courses/csv404/fi.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Huomio: Tämän kurssin videot ovat saatavilla vain englanniksi. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/fr.md b/courses/csv404/fr.md deleted file mode 100644 index 893ee7891cb..00000000000 --- a/courses/csv404/fr.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Note : Les vidéos de ce cours sont uniquement disponibles en anglais. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/hi.md b/courses/csv404/hi.md deleted file mode 100644 index 037b2aad6bc..00000000000 --- a/courses/csv404/hi.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -नोट: इस कोर्स के वीडियो केवल अंग्रेजी में उपलब्ध हैं। - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/id.md b/courses/csv404/id.md deleted file mode 100644 index 34d5b7743af..00000000000 --- a/courses/csv404/id.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Catatan: Video untuk kursus ini hanya tersedia dalam bahasa Inggris. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/it.md b/courses/csv404/it.md deleted file mode 100644 index 1a2e64caed0..00000000000 --- a/courses/csv404/it.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Nota: I video di questo corso sono disponibili solo in inglese. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/ja.md b/courses/csv404/ja.md deleted file mode 100644 index afd5dfa59eb..00000000000 --- a/courses/csv404/ja.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -注意：このコースの動画は英語のみで提供されています。 - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/ko.md b/courses/csv404/ko.md deleted file mode 100644 index c05839e5190..00000000000 --- a/courses/csv404/ko.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -참고: 이 강좌의 동영상은 영어로만 제공됩니다. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/nb-NO.md b/courses/csv404/nb-NO.md deleted file mode 100644 index d7c6f3392f3..00000000000 --- a/courses/csv404/nb-NO.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Merk: Videoene til dette kurset er kun tilgjengelige på engelsk. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/nl.md b/courses/csv404/nl.md deleted file mode 100644 index 8ac4ab0d690..00000000000 --- a/courses/csv404/nl.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Opmerking: De video's voor deze cursus zijn alleen beschikbaar in het Engels. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/pl.md b/courses/csv404/pl.md deleted file mode 100644 index 0c85057b47e..00000000000 --- a/courses/csv404/pl.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Uwaga: Filmy do tego kursu są dostępne tylko w języku angielskim. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/pt.md b/courses/csv404/pt.md deleted file mode 100644 index 36fed9cdac0..00000000000 --- a/courses/csv404/pt.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Nota: Os vídeos deste curso estão disponíveis apenas em inglês. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/quizz/000/en.yml b/courses/csv404/quizz/000/en.yml new file mode 100644 index 00000000000..266b947623b --- /dev/null +++ b/courses/csv404/quizz/000/en.yml @@ -0,0 +1,12 @@ +question: What role do intermediate Lightning nodes play when routing a Taproot Assets payment? +answer: They forward standard satoshi payments with no built-in awareness that assets are involved +wrong_answers: + - They convert assets between different denominations at each hop along the routing path + - They validate the asset proofs before forwarding the payment to the next node in line + - They store asset metadata on behalf of the network nodes for later dispute verification purposes +explanation: >- + In the Taproot Assets Lightning architecture, only the edge nodes at the + endpoints of a payment deal with assets. All intermediate nodes along the + route simply forward standard satoshi-denominated Lightning payments, with + no knowledge that assets are involved at the endpoints. +reviewed: false diff --git a/courses/csv404/quizz/000/question.yml b/courses/csv404/quizz/000/question.yml new file mode 100644 index 00000000000..c404c2c6e2d --- /dev/null +++ b/courses/csv404/quizz/000/question.yml @@ -0,0 +1,7 @@ +id: 4826b645-0ff5-4449-976d-7668b433a575 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/001/en.yml b/courses/csv404/quizz/001/en.yml new file mode 100644 index 00000000000..bcccc6439c2 --- /dev/null +++ b/courses/csv404/quizz/001/en.yml @@ -0,0 +1,12 @@ +question: What mechanism does the Taproot Assets Protocol use to embed asset data in Bitcoin transactions without revealing it publicly? +answer: Client-side validation with cryptographic proofs that only holders can verify +wrong_answers: + - OP_RETURN data fields that store encrypted asset information in each transaction + - Segregated witness extensions that carry asset metadata alongside signatures + - A sidechain anchoring mechanism that periodically commits asset state to Bitcoin +explanation: >- + Taproot Assets uses client-side validation, meaning asset data is committed + to the blockchain via a taptweak but is only visible to parties who possess + the corresponding cryptographic proofs. To any external observer, the + transaction looks like an ordinary Taproot transaction. +reviewed: false diff --git a/courses/csv404/quizz/001/question.yml b/courses/csv404/quizz/001/question.yml new file mode 100644 index 00000000000..56a7efc8cdd --- /dev/null +++ b/courses/csv404/quizz/001/question.yml @@ -0,0 +1,7 @@ +id: 3fa5ac79-4989-4b6e-a21f-0b3637ac1c86 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/002/en.yml b/courses/csv404/quizz/002/en.yml new file mode 100644 index 00000000000..2406a643f72 --- /dev/null +++ b/courses/csv404/quizz/002/en.yml @@ -0,0 +1,12 @@ +question: What data structure does TAPD use to organize and commit asset information? +answer: Merkle Sum Sparse Merkle Trees (MS-SMT) for committing asset data +wrong_answers: + - Patricia Merkle Tries adapted from Ethereum's state model + - Standard binary Merkle trees identical to Bitcoin's block structure + - Directed acyclic graphs stored in the transaction witness +explanation: >- + TAPD constructs Merkle Sum Sparse Merkle Trees (MS-SMT) to store all asset + data. These specialized structures combine the properties of sparse Merkle + trees (which enable absence proofs) with Merkle sum trees (which provide + anti-inflation guarantees by propagating numeric values to the root). +reviewed: false diff --git a/courses/csv404/quizz/002/question.yml b/courses/csv404/quizz/002/question.yml new file mode 100644 index 00000000000..cbcc1a9a58a --- /dev/null +++ b/courses/csv404/quizz/002/question.yml @@ -0,0 +1,7 @@ +id: 7681a5fc-af80-486a-98d4-d0a708ab6222 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/003/en.yml b/courses/csv404/quizz/003/en.yml new file mode 100644 index 00000000000..b82ce241c42 --- /dev/null +++ b/courses/csv404/quizz/003/en.yml @@ -0,0 +1,12 @@ +question: What consensus change does the Taproot Assets Protocol require to function on Bitcoin? +answer: None — it is fully opt-in and requires no consensus changes +wrong_answers: + - A soft fork to enable asset-aware transaction validation rules + - A new opcode dedicated to Merkle tree verification inside scripts + - An extension to the Taproot script versioning system for asset commitments +explanation: >- + The Taproot Assets Protocol is designed to work entirely within Bitcoin's + existing consensus rules. It leverages the design space opened by the + Taproot upgrade (BIP 341) to embed asset data via the taptweak, without + requiring any additional protocol-level changes. +reviewed: false diff --git a/courses/csv404/quizz/003/question.yml b/courses/csv404/quizz/003/question.yml new file mode 100644 index 00000000000..eaebd7c3fda --- /dev/null +++ b/courses/csv404/quizz/003/question.yml @@ -0,0 +1,7 @@ +id: 741465a3-0832-4584-824f-09bba4be8360 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/004/en.yml b/courses/csv404/quizz/004/en.yml new file mode 100644 index 00000000000..d5f544f3181 --- /dev/null +++ b/courses/csv404/quizz/004/en.yml @@ -0,0 +1,13 @@ +question: When Alice sends 100 of her 1,000 beefbucks to Bob on-chain, how does the protocol handle the state change? +answer: Two new Merkle trees are built, one giving Alice 900 and Bob 100, each committed to its own transaction output +wrong_answers: + - The existing Merkle tree is simply updated in place, adjusting the balances recorded for both parties + - A single new Merkle tree is created containing both balances as separate leaves in the same transaction output + - The transaction creates an on-chain script output that enforces the split and tracks future transfers +explanation: >- + On-chain Taproot Assets transfers work by splitting the current Merkle tree + into two new trees reflecting the updated balances. Alice's asset-bearing + UTXO is consumed as an input, and the transaction creates at least two + outputs: one committing Alice's updated tree (900 beefbucks) and one + committing Bob's new tree (100 beefbucks). +reviewed: false diff --git a/courses/csv404/quizz/004/question.yml b/courses/csv404/quizz/004/question.yml new file mode 100644 index 00000000000..82da418d882 --- /dev/null +++ b/courses/csv404/quizz/004/question.yml @@ -0,0 +1,7 @@ +id: 3e21f928-a9d9-47db-90d9-972e7fd7c18e +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/005/en.yml b/courses/csv404/quizz/005/en.yml new file mode 100644 index 00000000000..724c2486c3f --- /dev/null +++ b/courses/csv404/quizz/005/en.yml @@ -0,0 +1,13 @@ +question: What is the function of an edge node in the Taproot Assets Lightning architecture? +answer: It sits at the boundary between asset channels and satoshi channels, converting between the two +wrong_answers: + - It validates all asset transactions across the entire Lightning Network before they are confirmed on-chain + - It stores the complete issuance history of every Taproot Asset for network-wide verification purposes + - It relays asset metadata between Lightning nodes that do not support the Taproot Assets Protocol +explanation: >- + An edge node sits at the boundary of the Lightning Network where asset + channels meet regular satoshi channels. When a cross-asset payment is + initiated, the edge node converts the asset into satoshis (or vice versa), + allowing the payment to route through standard Lightning liquidity. A + second edge node on the other side performs the reverse conversion. +reviewed: false diff --git a/courses/csv404/quizz/005/question.yml b/courses/csv404/quizz/005/question.yml new file mode 100644 index 00000000000..00d5a516487 --- /dev/null +++ b/courses/csv404/quizz/005/question.yml @@ -0,0 +1,7 @@ +id: d96d89b7-45f9-4ad9-98b4-83afad25730e +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/006/en.yml b/courses/csv404/quizz/006/en.yml new file mode 100644 index 00000000000..2e368b132de --- /dev/null +++ b/courses/csv404/quizz/006/en.yml @@ -0,0 +1,13 @@ +question: How does TAPTweak commit asset data to the Bitcoin blockchain? +answer: It embeds the Merkle tree root hash into the Bitcoin script tree via a Taproot address +wrong_answers: + - It writes the full raw asset ledger data directly into the witness field of the transaction + - It creates an OP_RETURN output containing a double SHA-256 hash of the complete asset state + - It anchors the asset data to a separate federated sidechain block referenced in the transaction +explanation: >- + TAPTweak takes the root hash of the collection of Merkle Sum Sparse Merkle + Trees, adds it to the Bitcoin script tree, and embeds it into a Bitcoin + address. The resulting on-chain transaction is indistinguishable from a + regular Taproot transaction, preserving privacy while cryptographically + committing the asset state. +reviewed: false diff --git a/courses/csv404/quizz/006/question.yml b/courses/csv404/quizz/006/question.yml new file mode 100644 index 00000000000..fd5896f8c62 --- /dev/null +++ b/courses/csv404/quizz/006/question.yml @@ -0,0 +1,7 @@ +id: 6fed5d09-6921-4d97-bf1c-a4918a686675 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/007/en.yml b/courses/csv404/quizz/007/en.yml new file mode 100644 index 00000000000..b563becc103 --- /dev/null +++ b/courses/csv404/quizz/007/en.yml @@ -0,0 +1,13 @@ +question: Why can a Taproot Assets minting transaction remain indistinguishable from a regular Taproot transaction on the blockchain? +answer: The asset data is committed via taptweak, visible only to holders of the cryptographic proofs +wrong_answers: + - The asset data is encrypted with the minter's public key and stored in the witness field permanently + - Taproot Assets use a dedicated mempool relay layer that standard Bitcoin nodes cannot see or access + - The minting data is stored entirely off-chain on a federated server and never touches the Bitcoin blockchain +explanation: >- + Because asset data is embedded via TAPTweak into the Taproot script tree, + the on-chain transaction carries no visible indication of asset activity. + Only parties who possess the corresponding cryptographic proofs can verify + that asset data was committed. This is the core property of client-side + validation — the blockchain enforces commitment without revealing content. +reviewed: false diff --git a/courses/csv404/quizz/007/question.yml b/courses/csv404/quizz/007/question.yml new file mode 100644 index 00000000000..8874b89a39a --- /dev/null +++ b/courses/csv404/quizz/007/question.yml @@ -0,0 +1,7 @@ +id: c023cc5d-b7ec-4f37-91ea-a280d4cc7568 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/008/en.yml b/courses/csv404/quizz/008/en.yml new file mode 100644 index 00000000000..942f1a6ace6 --- /dev/null +++ b/courses/csv404/quizz/008/en.yml @@ -0,0 +1,14 @@ +question: In a cross-asset Lightning payment where Bob sends USD stablecoins and Elena receives euro stablecoins, what is the exact payment flow? +answer: Bob's edge node converts USD to satoshis, it routes through standard Lightning, and Elena's node converts satoshis to euros +wrong_answers: + - The payment is routed through specialized asset-aware channels that natively support multi-currency conversion at every hop taken + - A central exchange node matches the USD and EUR orders directly before routing the settled payment through the network + - The USD stablecoins are burned entirely at Bob's node and new EUR stablecoins are minted directly at Elena's edge node +explanation: >- + Cross-asset Lightning payments rely on two edge nodes and the standard + Lightning Network in between. Bob's edge node accepts his USD stablecoins + and forwards the equivalent value as a satoshi Lightning payment. That + payment routes through ordinary channels until it reaches Elena's edge + node, which converts the received satoshis into euro stablecoins. The + intermediate network never touches the assets directly. +reviewed: false diff --git a/courses/csv404/quizz/008/question.yml b/courses/csv404/quizz/008/question.yml new file mode 100644 index 00000000000..46a7f7e2928 --- /dev/null +++ b/courses/csv404/quizz/008/question.yml @@ -0,0 +1,7 @@ +id: 8f3eea88-70b9-4e00-905a-a8d5fcdf5a2c +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/009/en.yml b/courses/csv404/quizz/009/en.yml new file mode 100644 index 00000000000..7d93234da5d --- /dev/null +++ b/courses/csv404/quizz/009/en.yml @@ -0,0 +1,13 @@ +question: What distinguishes an internal Taproot Assets transaction from a standard on-chain transfer? +answer: Assets move between leaves within the same set of Merkle trees, without splitting value across separate outputs +wrong_answers: + - Internal transactions skip the on-chain Bitcoin transaction needed to commit the state change entirely + - Internal transactions bypass proof verification and rely solely on node trust and local disk caches + - Internal transactions can only move assets within a single Lightning payment channel between two peers +explanation: >- + In an internal transaction, assets are reorganized between leaves within the + same set of Merkle trees, rather than being split into separate trees + committed to different outputs. However, an on-chain Bitcoin transaction is + still required to commit the updated Merkle root, ensuring that the state + change is anchored to the blockchain like any other Taproot Assets operation. +reviewed: false diff --git a/courses/csv404/quizz/009/question.yml b/courses/csv404/quizz/009/question.yml new file mode 100644 index 00000000000..560afb2f9fa --- /dev/null +++ b/courses/csv404/quizz/009/question.yml @@ -0,0 +1,7 @@ +id: 899a011e-d279-4718-90da-99dd05c99608 +chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/010/en.yml b/courses/csv404/quizz/010/en.yml new file mode 100644 index 00000000000..59478cc2f34 --- /dev/null +++ b/courses/csv404/quizz/010/en.yml @@ -0,0 +1,9 @@ +question: "What was the Taproot Assets Protocol (TAP) originally known as?" +answer: "Taproot Asset Representation Overlay (Taro)" +wrong_answers: + - "Taproot Asset Registration Overlay Network (Taro)" + - "Taproot Asset Routing Overlay Protocol (Taro)" + - "Taproot Asset Replication Overlay Layer (Taro)" +explanation: >- + TAP was originally called the Taproot Asset Representation Overlay, abbreviated as Taro. The protocol was later renamed to the Taproot Assets Protocol to better reflect its expanded scope. The key word is "Representation," indicating the protocol's role in representing arbitrary assets on Bitcoin's blockchain. +reviewed: false diff --git a/courses/csv404/quizz/010/question.yml b/courses/csv404/quizz/010/question.yml new file mode 100644 index 00000000000..f7751ab7a9a --- /dev/null +++ b/courses/csv404/quizz/010/question.yml @@ -0,0 +1,7 @@ +id: "e33ff402-2990-4ec8-aaa7-3481f2602a0d" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/011/en.yml b/courses/csv404/quizz/011/en.yml new file mode 100644 index 00000000000..36d7ebdd0be --- /dev/null +++ b/courses/csv404/quizz/011/en.yml @@ -0,0 +1,9 @@ +question: "How many on-chain Taproot transactions are required to create multiple Taproot assets?" +answer: "A single on-chain Taproot transaction, with no theoretical limit on the number of assets" +wrong_answers: + - "One transaction per asset, each requiring a separate on-chain confirmation" + - "A minimum of two transactions: one for the asset metadata and one for the asset itself" + - "Multiple transactions batched together for confirmation within a single Bitcoin block" +explanation: >- + Creating one or many Taproot assets requires only a single on-chain Taproot transaction. There is no theoretical limit to the number of assets that can be produced within that one transaction. This efficiency is a key advantage of the protocol, as asset data is embedded within a regular Taproot transaction. +reviewed: false diff --git a/courses/csv404/quizz/011/question.yml b/courses/csv404/quizz/011/question.yml new file mode 100644 index 00000000000..00b34c3d713 --- /dev/null +++ b/courses/csv404/quizz/011/question.yml @@ -0,0 +1,7 @@ +id: "54280131-79b0-47d9-875e-af105b0b3c4e" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/012/en.yml b/courses/csv404/quizz/012/en.yml new file mode 100644 index 00000000000..d79fc481bca --- /dev/null +++ b/courses/csv404/quizz/012/en.yml @@ -0,0 +1,9 @@ +question: "Which three inputs are hashed together using SHA-256 to compute a Taproot Asset ID?" +answer: "The genesis outpoint, the asset tag, and the raw asset metadata" +wrong_answers: + - "The internal public key, the Merkle root, and the asset tag" + - "The transaction ID, the block hash, and the asset supply" + - "The genesis outpoint, the asset supply, and the issuer's key" +explanation: >- + The Asset ID is computed as sha256(genesis_outpoint || asset_tag || asset_meta). The genesis outpoint anchors the asset to its specific creation point on the Bitcoin blockchain, the asset tag provides the asset's name, and the asset meta contains any associated metadata. This formula ensures each asset has a deterministic and unique identifier tied to its on-chain origin. +reviewed: false diff --git a/courses/csv404/quizz/012/question.yml b/courses/csv404/quizz/012/question.yml new file mode 100644 index 00000000000..906e95cfa74 --- /dev/null +++ b/courses/csv404/quizz/012/question.yml @@ -0,0 +1,7 @@ +id: "5dd40e99-c280-4c48-a815-173fc2e96898" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/013/en.yml b/courses/csv404/quizz/013/en.yml new file mode 100644 index 00000000000..ba5f4ff5628 --- /dev/null +++ b/courses/csv404/quizz/013/en.yml @@ -0,0 +1,9 @@ +question: "How does a Sparse Merkle Tree prove that an asset does not exist?" +answer: "By showing that the leaf position determined by the SHA-256 digest of the asset data is empty" +wrong_answers: + - "By providing a signed attestation from the asset issuer confirming the asset was never created" + - "By scanning every leaf in the tree and confirming the asset is absent from all positions" + - "By verifying that the Merkle root hash does not match any known asset commitment" +explanation: >- + In a Sparse Merkle Tree, each object is stored at a leaf position determined by the SHA-256 digest of its data, creating a deterministic placement. To prove an asset does not exist, you simply demonstrate that the expected leaf position is empty (contains a null hash). This is far more efficient than scanning the entire tree, as the sparse nature means most leaves are empty by default. +reviewed: false diff --git a/courses/csv404/quizz/013/question.yml b/courses/csv404/quizz/013/question.yml new file mode 100644 index 00000000000..911a5631b32 --- /dev/null +++ b/courses/csv404/quizz/013/question.yml @@ -0,0 +1,7 @@ +id: "805353c2-2fc3-4427-81b3-42dea13addc5" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/014/en.yml b/courses/csv404/quizz/014/en.yml new file mode 100644 index 00000000000..17ca06aea67 --- /dev/null +++ b/courses/csv404/quizz/014/en.yml @@ -0,0 +1,9 @@ +question: "In the tap tweak formula Q = P + H(P || c) * G, what does the variable c represent?" +answer: "The MS-SMT commitment, i.e. the root hash of the Merkle Sum Sparse Merkle Tree structure" +wrong_answers: + - "The cryptographic challenge value derived from the transaction signature and nonce" + - "The coin amount, in satoshis, locked within the Taproot output script itself" + - "The compressed public key belonging to the intended asset recipient's wallet" +explanation: >- + In the formula Q = P + H(P || c) * G, P is the internal public key, c is the MS-SMT commitment (the root of the Merkle Sum Sparse Merkle Tree), H is a hash function, and G is the generator point. This tap tweak creates an unbreakable cryptographic link between the on-chain Bitcoin transaction and the off-chain asset data stored in the MS-SMT. +reviewed: false diff --git a/courses/csv404/quizz/014/question.yml b/courses/csv404/quizz/014/question.yml new file mode 100644 index 00000000000..88a970dd97f --- /dev/null +++ b/courses/csv404/quizz/014/question.yml @@ -0,0 +1,7 @@ +id: "bccc4073-0236-40da-af91-6ee01cfbfa2a" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/015/en.yml b/courses/csv404/quizz/015/en.yml new file mode 100644 index 00000000000..d1a4db63981 --- /dev/null +++ b/courses/csv404/quizz/015/en.yml @@ -0,0 +1,9 @@ +question: "How does client-side validation work in the Taproot Assets Protocol?" +answer: "The recipient rebuilds a partial MS-SMT, tweaks the issuer's key with the commitment, checks the genesis tx" +wrong_answers: + - "The recipient downloads the entire Bitcoin blockchain history and scans it for Taproot Asset transactions" + - "A centralized validation server checks the asset's cryptographic proofs and issues a signed certificate" + - "Every full node on the Bitcoin network validates each Taproot Asset transfer under consensus rules" +explanation: >- + TAP relies on client-side validation, meaning recipients do not need the complete blockchain history to verify an asset's legitimacy. Instead, they reconstruct a partial MS-SMT, tweak the issuer's public key using the commitment, and verify that the corresponding genesis transaction exists on-chain. This approach keeps validation lightweight and off-chain while still anchoring trust in Bitcoin's blockchain. +reviewed: false diff --git a/courses/csv404/quizz/015/question.yml b/courses/csv404/quizz/015/question.yml new file mode 100644 index 00000000000..98ac42d9a07 --- /dev/null +++ b/courses/csv404/quizz/015/question.yml @@ -0,0 +1,7 @@ +id: "083a5bab-7689-4821-aa76-732afc057b31" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/016/en.yml b/courses/csv404/quizz/016/en.yml new file mode 100644 index 00000000000..152f6a9f6b7 --- /dev/null +++ b/courses/csv404/quizz/016/en.yml @@ -0,0 +1,9 @@ +question: "What happens to the proof chain if a UTXO containing Taproot assets is spent without a valid new MS-SMT commitment?" +answer: "The proof is invalidated, breaking the whole chain of ownership back to the genesis output" +wrong_answers: + - "The assets are automatically returned to the previous owner via a timelock" + - "The protocol creates a temporary proof placeholder until a valid commitment is submitted" + - "The assets remain valid but become locked until a new MS-SMT commitment is broadcast" +explanation: >- + Every asset transfer generates a cryptographic proof, and these proofs form a chain tracing the asset's ownership history back to its genesis output. If a UTXO is spent without a valid new MS-SMT commitment, the proof is invalidated entirely. This means the assets are effectively destroyed, as no valid proof chain can be constructed to demonstrate ownership. +reviewed: false diff --git a/courses/csv404/quizz/016/question.yml b/courses/csv404/quizz/016/question.yml new file mode 100644 index 00000000000..0fe9845b90f --- /dev/null +++ b/courses/csv404/quizz/016/question.yml @@ -0,0 +1,7 @@ +id: "e1f34fc9-de21-489e-bc55-9263289daab5" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: hard +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/017/en.yml b/courses/csv404/quizz/017/en.yml new file mode 100644 index 00000000000..3bd756ccfd2 --- /dev/null +++ b/courses/csv404/quizz/017/en.yml @@ -0,0 +1,9 @@ +question: "When sending Taproot assets over the Lightning Network, what do intermediate routing nodes forward?" +answer: "Ordinary satoshis, with no awareness whatsoever that the endpoints are dealing in Taproot assets" +wrong_answers: + - "Encrypted Taproot Asset packets that are decoded and re-signed at each hop along the route" + - "Special TAP-enabled HTLCs that carry both the asset data and the satoshi value directly" + - "Asset proofs wrapped in onion-routed messages alongside the Lightning payment amount" +explanation: >- + When sending TAP assets over Lightning, only the sending and receiving nodes need Taproot Asset-enabled channels holding the specific asset. All intermediate nodes along the payment route simply forward ordinary satoshis, completely unaware that the endpoints are dealing in Taproot assets. This design leverages the existing Lightning routing infrastructure without requiring TAP awareness at every hop. +reviewed: false diff --git a/courses/csv404/quizz/017/question.yml b/courses/csv404/quizz/017/question.yml new file mode 100644 index 00000000000..fee488e4c6f --- /dev/null +++ b/courses/csv404/quizz/017/question.yml @@ -0,0 +1,7 @@ +id: "b956a46a-00dc-4ce6-8496-0a3456a91725" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/018/en.yml b/courses/csv404/quizz/018/en.yml new file mode 100644 index 00000000000..ddc2fa6d4c5 --- /dev/null +++ b/courses/csv404/quizz/018/en.yml @@ -0,0 +1,9 @@ +question: "What is the RFQ mechanism in the context of Taproot Assets on Lightning?" +answer: "A Request for Quote system enabling automatic exchange between Bitcoin invoices and Taproot assets" +wrong_answers: + - "A Request for Finality Queue that batches Taproot asset transfers into a Lightning commitment" + - "A Relay Forwarding Queue that prioritizes Taproot asset HTLCs over regular Lightning payments" + - "A Rebalancing Fee Quotient that calculates optimal channel liquidity for Taproot asset transfers" +explanation: >- + RFQ stands for Request for Quote, and it is a mechanism that supports automatic asset exchange within the Lightning integration of TAP. It allows a Lightning invoice denominated in Bitcoin to be paid using a Taproot asset, or vice versa, with the conversion handled seamlessly. This opens the door to cross-asset Lightning payments while leveraging the full sophistication of the protocol. +reviewed: false diff --git a/courses/csv404/quizz/018/question.yml b/courses/csv404/quizz/018/question.yml new file mode 100644 index 00000000000..1bd00b76f9c --- /dev/null +++ b/courses/csv404/quizz/018/question.yml @@ -0,0 +1,7 @@ +id: "d7755d68-0ba9-4485-854c-cd8f11298d4f" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/019/en.yml b/courses/csv404/quizz/019/en.yml new file mode 100644 index 00000000000..45a1b6861fa --- /dev/null +++ b/courses/csv404/quizz/019/en.yml @@ -0,0 +1,9 @@ +question: "What role do Universe services play in the Taproot Assets ecosystem?" +answer: "They provide off-chain infrastructure for asset discovery and proof distribution, like block explorers for Taproot data" +wrong_answers: + - "They serve as mandatory consensus validators that must confirm every Taproot Asset transaction before final on-chain settlement occurs" + - "They act as centralized custodians that hold and safeguard all Taproot assets on behalf of their registered users" + - "They manage and rotate the private keys required to sign and authorize Taproot Asset transfers between counterparties" +explanation: >- + Universe services function as off-chain data stores for asset discovery and proof distribution, comparable to how Bitcoin block explorers work for blockchain data. They hold no protocol-level privileges and anyone can run one. By keeping detailed transaction histories off-chain while anchoring cryptographic commitments on-chain, the protocol achieves scalability without sacrificing security. +reviewed: false diff --git a/courses/csv404/quizz/019/question.yml b/courses/csv404/quizz/019/question.yml new file mode 100644 index 00000000000..604bbf6b5f4 --- /dev/null +++ b/courses/csv404/quizz/019/question.yml @@ -0,0 +1,7 @@ +id: "5653fcc2-c6be-49a7-9a90-1130877ee30f" +chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/020/en.yml b/courses/csv404/quizz/020/en.yml new file mode 100644 index 00000000000..0556d87e4b2 --- /dev/null +++ b/courses/csv404/quizz/020/en.yml @@ -0,0 +1,9 @@ +question: "What three properties must the Merkle Sum Sparse Merkle Tree prove for a Taproot asset?" +answer: "Ownership, non-inflation, and transfer" +wrong_answers: + - "Confidentiality, integrity, and availability" + - "Authentication, authorization, and accounting" + - "Issuance, routing, and settlement finality" +explanation: >- + The MS-SMT must prove three things: ownership (that you hold the asset), non-inflation (that you have not created more units than declared), and transfer (that when you send assets, you can prove you no longer own what you sent). These three properties are elegantly solved by the combined sparse and sum components of the tree structure. +reviewed: false diff --git a/courses/csv404/quizz/020/question.yml b/courses/csv404/quizz/020/question.yml new file mode 100644 index 00000000000..995529c3c0d --- /dev/null +++ b/courses/csv404/quizz/020/question.yml @@ -0,0 +1,7 @@ +id: "2b660347-580b-4c25-b5b1-9784d230b99c" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/021/en.yml b/courses/csv404/quizz/021/en.yml new file mode 100644 index 00000000000..eb0c727e26d --- /dev/null +++ b/courses/csv404/quizz/021/en.yml @@ -0,0 +1,9 @@ +question: "How does the Asset ID determine the position of asset data in a Sparse Merkle Tree?" +answer: "The binary representation of the Asset ID acts as a navigation map, with each bit steering left or right" +wrong_answers: + - "The Asset ID is hashed and the resulting digest is used as an index into a sequential array of sorted leaves" + - "The Asset ID is sorted alphabetically and assigned the next available empty leaf position in the tree" + - "The Asset ID is converted to a decimal number and placed at that numbered position within the tree" +explanation: >- + When TAPD creates an asset, the binary representation of the Asset ID serves as a deterministic map through the tree. Each bit (zero or one) tells you whether to go left or right as you descend from the root to a leaf. This means the Asset ID defines exactly where in the tree the asset data lives, enabling both efficient inclusion and exclusion proofs. +reviewed: false diff --git a/courses/csv404/quizz/021/question.yml b/courses/csv404/quizz/021/question.yml new file mode 100644 index 00000000000..4511a1ccbc8 --- /dev/null +++ b/courses/csv404/quizz/021/question.yml @@ -0,0 +1,7 @@ +id: "c6f44208-53b8-46ea-8595-35d6b17478f3" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/022/en.yml b/courses/csv404/quizz/022/en.yml new file mode 100644 index 00000000000..4feab87e90a --- /dev/null +++ b/courses/csv404/quizz/022/en.yml @@ -0,0 +1,9 @@ +question: "Which two problems does the sparse component of the MS-SMT solve?" +answer: "Proving ownership through Merkle inclusion proofs and proving transfer completion through exclusion proofs" +wrong_answers: + - "Preventing double-spending through locktime enforcement and validating asset metadata via hash checks" + - "Ensuring transaction finality through confirmation depth and verifying supply through root summation" + - "Authenticating the issuer through digital signatures and encrypting asset data via symmetric keys" +explanation: >- + The sparse component solves problems one (ownership) and three (transfer) from the chapter's framework. Ownership is proven via a Merkle inclusion proof following the path defined by the Asset ID. Transfer completion is proven via an exclusion proof, showing that the asset data at the original leaf position is now empty. The deterministic placement of data in the tree makes both proof types efficient. +reviewed: false diff --git a/courses/csv404/quizz/022/question.yml b/courses/csv404/quizz/022/question.yml new file mode 100644 index 00000000000..36f5679a0f4 --- /dev/null +++ b/courses/csv404/quizz/022/question.yml @@ -0,0 +1,7 @@ +id: "22396c74-473c-4489-9b9e-fac4c933a617" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/023/en.yml b/courses/csv404/quizz/023/en.yml new file mode 100644 index 00000000000..656b39700df --- /dev/null +++ b/courses/csv404/quizz/023/en.yml @@ -0,0 +1,9 @@ +question: "If you mint 100 beefbucks and send 50 to Bob, what happens if you try to claim you still have 100?" +answer: "The Merkle proofs turn inconsistent, effectively burning the coins since supply can't inflate without breaking your own proofs" +wrong_answers: + - "The network rejects the transaction outright at the base consensus level and reverts the entire transfer back to Bob" + - "The protocol automatically reduces your local balance to 50 and issues a broadcast warning to all connected peers" + - "Bob's node independently detects the balance discrepancy and broadcasts a fraud proof to invalidate your claim" +explanation: >- + The sum component of the MS-SMT prevents inflation by propagating values up the tree. If you sent 50 beefbucks to Bob, your leaf should change from 100 to 50 and the sums propagate to the root. Claiming you still have 100 while also having sent 50 would make the Merkle proofs inconsistent, as the root sum would not match. This means you cannot inflate the supply without invalidating your own proofs, effectively burning your assets. +reviewed: false diff --git a/courses/csv404/quizz/023/question.yml b/courses/csv404/quizz/023/question.yml new file mode 100644 index 00000000000..cc085d2a6ed --- /dev/null +++ b/courses/csv404/quizz/023/question.yml @@ -0,0 +1,7 @@ +id: "04ed58cd-60ac-4531-adac-75f0112794fa" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: hard +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/024/en.yml b/courses/csv404/quizz/024/en.yml new file mode 100644 index 00000000000..9b45d128788 --- /dev/null +++ b/courses/csv404/quizz/024/en.yml @@ -0,0 +1,9 @@ +question: "What information does the root hash of a Merkle Sum Tree encode?" +answer: "The total combined quantity of all assets contained within the entire tree structure" +wrong_answers: + - "The number of individual leaves currently occupied in the tree at that depth" + - "The hash of the most recently added asset leaf and its full metadata field" + - "The public key of the entity that originally created the tree structure" +explanation: >- + In a Merkle Sum Tree, each leaf carries a numeric value representing an asset quantity, and every internal node holds the sum of all values in its subtree. Therefore, the root hash encodes the total of all assets in the entire structure. This summation property provides a powerful anti-inflation guarantee, as validators can confirm that no new units have been created out of thin air by checking the root sum. +reviewed: false diff --git a/courses/csv404/quizz/024/question.yml b/courses/csv404/quizz/024/question.yml new file mode 100644 index 00000000000..0db5e3582a8 --- /dev/null +++ b/courses/csv404/quizz/024/question.yml @@ -0,0 +1,7 @@ +id: "146c242e-c60b-4190-b752-3865a26f927e" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/025/en.yml b/courses/csv404/quizz/025/en.yml new file mode 100644 index 00000000000..26460ea208c --- /dev/null +++ b/courses/csv404/quizz/025/en.yml @@ -0,0 +1,9 @@ +question: "What are the three layers of the Merkle forest in the Taproot Assets data structure, from bottom to top?" +answer: "Asset level (individual asset data), group level (fungible asset grouping), and Bitcoin Taproot tree (script tree commitment)" +wrong_answers: + - "Transaction level (raw transaction data), channel level (Lightning channel state), and network level (peer-to-peer routing metadata)" + - "Leaf level (raw key-value pairs), branch level (intermediate hash nodes), and root level (final Merkle commitment hash value)" + - "UTXO level (unspent transaction outputs), block level (confirmed transactions), and chain level (full blockchain state history)" +explanation: >- + The complete MS-SMT data structure consists of three layers. The bottom asset level stores individual asset data including name, metadata, and balances. The middle group level groups fungible assets together, enabling features like multi-tranche minting where assets minted across different rounds share the same group. The top layer is the standard Bitcoin Taproot script tree, into which the entire Merkle forest is committed. +reviewed: false diff --git a/courses/csv404/quizz/025/question.yml b/courses/csv404/quizz/025/question.yml new file mode 100644 index 00000000000..efad93be8ab --- /dev/null +++ b/courses/csv404/quizz/025/question.yml @@ -0,0 +1,7 @@ +id: "a317e87d-1396-433a-ba64-2f155650eee4" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/026/en.yml b/courses/csv404/quizz/026/en.yml new file mode 100644 index 00000000000..6f4f9c0b92a --- /dev/null +++ b/courses/csv404/quizz/026/en.yml @@ -0,0 +1,9 @@ +question: "What feature does the group level of the Merkle forest enable for Taproot assets?" +answer: "Multi-tranche minting: assets minted across separate rounds stay fully interchangeable within one group" +wrong_answers: + - "Atomic swaps between different asset types without an on-chain confirmation transaction at all" + - "Parallel proof verification across multiple independent Merkle trees for faster validation" + - "Cross-chain bridging by linking the group commitment to external blockchain state roots" +explanation: >- + The group level sits above the asset level in the Merkle forest and groups fungible assets together. For example, all beefbucks minted across different rounds share the same group, making them interchangeable. This is what enables multi-tranche minting, where an issuer can create additional units of the same asset in separate minting events. Group key signatures can authorize these new minting rounds. +reviewed: false diff --git a/courses/csv404/quizz/026/question.yml b/courses/csv404/quizz/026/question.yml new file mode 100644 index 00000000000..7b34746f363 --- /dev/null +++ b/courses/csv404/quizz/026/question.yml @@ -0,0 +1,7 @@ +id: "905bff3a-5628-43fc-8374-02da02a6774b" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/027/en.yml b/courses/csv404/quizz/027/en.yml new file mode 100644 index 00000000000..5c6e946919c --- /dev/null +++ b/courses/csv404/quizz/027/en.yml @@ -0,0 +1,9 @@ +question: "How does the TAPTweak process embed the Merkle forest into a Bitcoin transaction?" +answer: "TAPD computes a single root hash from the Merkle forest and embeds it into a Bitcoin output via taptweak" +wrong_answers: + - "TAPD serializes the entire Merkle forest into OP_RETURN data fields across multiple transaction outputs" + - "TAPD encodes each tree layer as a separate witness element in the transaction's segregated witness data" + - "TAPD stores the Merkle forest in a sidechain and writes a cross-chain reference into the Bitcoin transaction" +explanation: >- + The TAPTweak process sums the entire Merkle forest up to a single root hash. That root hash is then embedded into a Bitcoin address using the taptweak formula Q = P + H(P || c) * G. The result is a standard-looking Bitcoin Taproot output that appears as an ordinary transaction to anyone examining the blockchain. Only parties possessing the asset proofs can verify that assets are embedded within it. +reviewed: false diff --git a/courses/csv404/quizz/027/question.yml b/courses/csv404/quizz/027/question.yml new file mode 100644 index 00000000000..fc9640b8060 --- /dev/null +++ b/courses/csv404/quizz/027/question.yml @@ -0,0 +1,7 @@ +id: "a59d9578-58b6-4bd4-875e-3588cabc46d2" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/028/en.yml b/courses/csv404/quizz/028/en.yml new file mode 100644 index 00000000000..7d7b485314a --- /dev/null +++ b/courses/csv404/quizz/028/en.yml @@ -0,0 +1,9 @@ +question: "What does a Taproot output containing embedded Taproot assets look like to an outside observer examining the blockchain?" +answer: "An ordinary Bitcoin Taproot transaction, indistinguishable from any other Taproot output" +wrong_answers: + - "A multisignature transaction that stands out due to an unusually large witness data size" + - "A transaction with OP_RETURN data clearly identifying it as a Taproot Asset commitment" + - "A specially formatted transaction with a unique version byte indicating embedded asset content" +explanation: >- + The TAPTweak mechanism produces a standard-looking Bitcoin Taproot output. To anyone examining the blockchain, it appears as an ordinary transaction. Only parties who possess the asset proofs (the paths through the Merkle forest) can verify that assets are embedded within it. This privacy property is inherited directly from Taproot's design. +reviewed: false diff --git a/courses/csv404/quizz/028/question.yml b/courses/csv404/quizz/028/question.yml new file mode 100644 index 00000000000..32e59635b57 --- /dev/null +++ b/courses/csv404/quizz/028/question.yml @@ -0,0 +1,7 @@ +id: "84eb50b2-36a9-44e3-9697-d2c18a8b6a13" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/029/en.yml b/courses/csv404/quizz/029/en.yml new file mode 100644 index 00000000000..b3ad294c16b --- /dev/null +++ b/courses/csv404/quizz/029/en.yml @@ -0,0 +1,9 @@ +question: "How does the layered Merkle forest structure support different levels of authorization?" +answer: "Signatures can be required at different levels: group keys authorize new minting rounds, asset keys control transfers" +wrong_answers: + - "Each layer uses a different hashing algorithm entirely, with SHA-256 at the asset level and SHA-512 at the group level" + - "Authorization is handled by a single master key at the root level, which delegates permissions to every child key" + - "Each layer maintains its own independent mempool tracking pending transactions awaiting confirmation on-chain" +explanation: >- + The layered structure of the Merkle forest allows requiring private key signatures at different levels, adding both security and flexibility. A group key signature can authorize new minting rounds, enabling multi-tranche issuance, while individual asset keys control the transfer of specific assets. This separation of authorization concerns provides fine-grained control over different asset operations. +reviewed: false diff --git a/courses/csv404/quizz/029/question.yml b/courses/csv404/quizz/029/question.yml new file mode 100644 index 00000000000..ab222f1b8a3 --- /dev/null +++ b/courses/csv404/quizz/029/question.yml @@ -0,0 +1,7 @@ +id: "0ff0ea29-837c-455f-a5e2-195f5fc14c48" +chapterId: "6b4ab386-9c4c-4a6c-a260-2cd589e1c9de" +difficulty: intermediate +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/030/en.yml b/courses/csv404/quizz/030/en.yml new file mode 100644 index 00000000000..f79bd651aee --- /dev/null +++ b/courses/csv404/quizz/030/en.yml @@ -0,0 +1,9 @@ +question: "What are the three layers of the TAPD software architecture stack, from bottom to top?" +answer: "Bitcoin Core (base layer), LND (Lightning layer), and TAPD (topmost asset layer)" +wrong_answers: + - "Bitcoin Core (base layer), TAPD (asset layer), and LND (Lightning layer)" + - "LND (Lightning layer), Bitcoin Core (base layer), and TAPD (asset layer)" + - "TAPD (asset layer), Bitcoin Core (base layer), and LND (Lightning layer)" +explanation: >- + The TAPD stack follows a deliberate three-tier architecture. Bitcoin Core forms the base layer handling blockchain data and transaction broadcasting. LND sits above it as the Lightning layer managing channels and private key custody. TAPD operates at the top as the asset layer, handling Taproot tweak computation, asset tracking, and proof management. +reviewed: false diff --git a/courses/csv404/quizz/030/question.yml b/courses/csv404/quizz/030/question.yml new file mode 100644 index 00000000000..ab1bf684ef9 --- /dev/null +++ b/courses/csv404/quizz/030/question.yml @@ -0,0 +1,7 @@ +id: "e3cec1d0-f6b9-4675-af57-45f14ea89aad" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/031/en.yml b/courses/csv404/quizz/031/en.yml new file mode 100644 index 00000000000..71dc6fd415d --- /dev/null +++ b/courses/csv404/quizz/031/en.yml @@ -0,0 +1,9 @@ +question: "What is the concept of 'segmented custody' in the TAPD architecture?" +answer: "LND holds the private keys while TAPD handles the Taproot Asset logic, neither overstepping its role" +wrong_answers: + - "Private keys are split into shares distributed across independent hardware security modules" + - "Each asset type is stored in its own separate custody vault with independent access controls" + - "Bitcoin Core manages on-chain custody while TAPD manages off-chain Lightning channel custody" +explanation: >- + Segmented custody refers to the deliberate separation of concerns between LND and TAPD. LND is responsible for holding private keys and managing channels, while TAPD handles the Taproot Asset logic including tweak computation, asset tracking, and proof management. Neither component oversteps its role, creating a clean security boundary between key management and asset protocol operations. +reviewed: false diff --git a/courses/csv404/quizz/031/question.yml b/courses/csv404/quizz/031/question.yml new file mode 100644 index 00000000000..909dfc310a6 --- /dev/null +++ b/courses/csv404/quizz/031/question.yml @@ -0,0 +1,7 @@ +id: "fadd17ef-8c9e-4714-ad8d-9f3071b64ec5" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/032/en.yml b/courses/csv404/quizz/032/en.yml new file mode 100644 index 00000000000..308c69936ac --- /dev/null +++ b/courses/csv404/quizz/032/en.yml @@ -0,0 +1,9 @@ +question: "What two binaries does TAPD ship with?" +answer: "tapd (the daemon listening on gRPC and REST) and tapcli (the command-line interface)" +wrong_answers: + - "tapd (the daemon) and tapwallet (a separate graphical wallet application for end users)" + - "tapcli (the command-line tool) and tapserver (the web-based management interface)" + - "tapd (the core daemon) and tapproof (a dedicated proof verification engine)" +explanation: >- + TAPD ships as two separate binaries. The first is tapd, which is the daemon itself that listens on gRPC (port 10029) and REST (port 8089) for incoming requests. The second is tapcli, the command-line interface used to interact with the daemon. Together they provide the full interface for managing Taproot assets. +reviewed: false diff --git a/courses/csv404/quizz/032/question.yml b/courses/csv404/quizz/032/question.yml new file mode 100644 index 00000000000..ffb47afb697 --- /dev/null +++ b/courses/csv404/quizz/032/question.yml @@ -0,0 +1,7 @@ +id: "0e06a89c-b59b-4887-8233-7cf1913ba785" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: easy +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/033/en.yml b/courses/csv404/quizz/033/en.yml new file mode 100644 index 00000000000..cf7c05e7a8b --- /dev/null +++ b/courses/csv404/quizz/033/en.yml @@ -0,0 +1,9 @@ +question: "What two LND credential files must be specified when starting the TAPD daemon?" +answer: "The admin macaroon (for authentication) and the TLS certificate (for encrypted communication)" +wrong_answers: + - "The channel backup file (for recovery) and the wallet seed phrase (for key derivation and rotation)" + - "The node public key (for identity) and the gossip certificate (for peer discovery on the network)" + - "The HSM token (for hardware security) and the session cookie (for API access control and rate limiting)" +explanation: >- + Starting the TAPD daemon requires specifying the paths to two LND credential files: the admin macaroon, which handles authentication to the LND node, and the TLS certificate, which ensures encrypted communication between TAPD and LND. Additionally, the network type and the LND address and port must be specified. +reviewed: false diff --git a/courses/csv404/quizz/033/question.yml b/courses/csv404/quizz/033/question.yml new file mode 100644 index 00000000000..24ed1a8b816 --- /dev/null +++ b/courses/csv404/quizz/033/question.yml @@ -0,0 +1,7 @@ +id: "6545bf9f-caee-4fbf-a5b5-fee84863113d" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: easy +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/034/en.yml b/courses/csv404/quizz/034/en.yml new file mode 100644 index 00000000000..3c3280a9b5c --- /dev/null +++ b/courses/csv404/quizz/034/en.yml @@ -0,0 +1,9 @@ +question: "What does the --skip_batch flag do when minting a Taproot asset with tapcli?" +answer: "It processes the mint request immediately rather than batching it with other pending mint requests" +wrong_answers: + - "It skips the on-chain confirmation requirement entirely, finalizing the asset in the mempool" + - "It bypasses the Merkle tree computation step to speed up large-scale asset creation" + - "It omits the asset metadata field to create a lightweight asset without extra data" +explanation: >- + When minting assets with tapcli, the --skip_batch flag instructs the daemon to process the minting request immediately instead of waiting to batch it with other pending minting requests. Without this flag, TAPD may hold the minting request to combine it with others into a single on-chain transaction for efficiency. Using --skip_batch is useful during testing or when you need immediate processing. +reviewed: false diff --git a/courses/csv404/quizz/034/question.yml b/courses/csv404/quizz/034/question.yml new file mode 100644 index 00000000000..5c3bb446c25 --- /dev/null +++ b/courses/csv404/quizz/034/question.yml @@ -0,0 +1,7 @@ +id: "9e9e92ac-f761-4b4d-ba21-24ccf2c60f2e" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/035/en.yml b/courses/csv404/quizz/035/en.yml new file mode 100644 index 00000000000..acb16e04b18 --- /dev/null +++ b/courses/csv404/quizz/035/en.yml @@ -0,0 +1,9 @@ +question: "How do TAP addresses differ from standard Bitcoin addresses when receiving Taproot assets?" +answer: "TAP addresses are unique to a specific asset and amount, unlike Bitcoin addresses that accept any amount" +wrong_answers: + - "TAP addresses use a different encoding scheme (bech64m) that is incompatible with standard Bitcoin wallets" + - "TAP addresses contain embedded routing information used for Lightning Network path discovery" + - "TAP addresses expire after a fixed time period and must be regenerated for each new asset transfer" +explanation: >- + Unlike standard Bitcoin addresses that can receive any arbitrary amount, TAP addresses are unique to each specific asset and amount combination. The recipient generates a TAP address by specifying both the asset ID and the exact amount they wish to receive. This means a new address must be generated for each distinct transfer, as the address encodes both which asset and how much of it should be received. +reviewed: false diff --git a/courses/csv404/quizz/035/question.yml b/courses/csv404/quizz/035/question.yml new file mode 100644 index 00000000000..fae6870ab6c --- /dev/null +++ b/courses/csv404/quizz/035/question.yml @@ -0,0 +1,7 @@ +id: "1e81e225-7c55-44a9-aa7b-715898a8a789" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: hard +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/036/en.yml b/courses/csv404/quizz/036/en.yml new file mode 100644 index 00000000000..d944cd5c696 --- /dev/null +++ b/courses/csv404/quizz/036/en.yml @@ -0,0 +1,9 @@ +question: "What minimum Go version is required to install TAPD from source?" +answer: "Go 1.18 or newer is required" +wrong_answers: + - "Go version 1.16 or greater" + - "Go version 1.21 or greater" + - "Go version 1.20 or greater" +explanation: >- + Installing TAPD from source requires Go version 1.18 or greater. The installation process compiles the Go source code and places both binaries (tapd and tapcli) in your system's Go path. Before installing TAPD, you must also have a working LND node connected to a Bitcoin backend. +reviewed: false diff --git a/courses/csv404/quizz/036/question.yml b/courses/csv404/quizz/036/question.yml new file mode 100644 index 00000000000..215a14fd10a --- /dev/null +++ b/courses/csv404/quizz/036/question.yml @@ -0,0 +1,7 @@ +id: "a6005378-efa0-4719-acca-a5d76abc5636" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: easy +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/037/en.yml b/courses/csv404/quizz/037/en.yml new file mode 100644 index 00000000000..425b08e95b0 --- /dev/null +++ b/courses/csv404/quizz/037/en.yml @@ -0,0 +1,9 @@ +question: "On which default ports does the TAPD daemon listen for gRPC and REST connections respectively?" +answer: "gRPC on port 10029 and REST on port 8089" +wrong_answers: + - "gRPC on port 8080 and REST on port 443" + - "gRPC on port 10009 and REST on port 8080" + - "gRPC on port 9735 and REST on port 10029" +explanation: >- + The TAPD daemon listens on two default ports: port 10029 for gRPC connections and port 8089 for REST connections. These are separate from LND's own default ports (10009 for gRPC and 8080 for REST). The gRPC interface provides full programmatic access, while the REST interface offers a more accessible HTTP-based API. +reviewed: false diff --git a/courses/csv404/quizz/037/question.yml b/courses/csv404/quizz/037/question.yml new file mode 100644 index 00000000000..85c6be7ef12 --- /dev/null +++ b/courses/csv404/quizz/037/question.yml @@ -0,0 +1,7 @@ +id: "3992a698-e1ef-49e8-bb73-d16bc7a49153" +chapterId: "e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27" +difficulty: easy +duration: 60 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/040/en.yml b/courses/csv404/quizz/040/en.yml new file mode 100644 index 00000000000..498a2c37b23 --- /dev/null +++ b/courses/csv404/quizz/040/en.yml @@ -0,0 +1,12 @@ +question: What happens to an asset's supply when it is minted with emission disabled (the default setting)? +answer: The supply is permanently and cryptographically capped at the initial mint amount +wrong_answers: + - The supply can be increased later by the issuer through a governance vote + - The supply is initially capped but can be unlocked through a protocol upgrade + - The supply is set to zero until the issuer manually activates distribution +explanation: >- + When emission is disabled, which is the default behavior in Taproot Assets + v0.2, the asset's supply is permanently and cryptographically locked at the + amount created during the initial mint. This provides a credible, enforceable + commitment about supply limitations that cannot be overridden by the issuer. +reviewed: false diff --git a/courses/csv404/quizz/040/question.yml b/courses/csv404/quizz/040/question.yml new file mode 100644 index 00000000000..03802fa5a40 --- /dev/null +++ b/courses/csv404/quizz/040/question.yml @@ -0,0 +1,7 @@ +id: f12d7fff-701c-4349-819d-82b473ad9d25 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/041/en.yml b/courses/csv404/quizz/041/en.yml new file mode 100644 index 00000000000..37317f80091 --- /dev/null +++ b/courses/csv404/quizz/041/en.yml @@ -0,0 +1,12 @@ +question: What does the asset group functionality in Taproot Assets v0.2 enable? +answer: Multiple minting rounds that produce fungible units sharing the same group ID +wrong_answers: + - Grouping different asset types into a single non-fungible collection + - Merging assets from different issuers into one unified liquidity pool + - Creating hierarchical asset structures where child assets inherit parent properties +explanation: >- + Asset groups allow an issuer to mint an asset with emission enabled, creating + a group that accommodates future minting rounds (tranches). Each subsequent + mint shares the same group ID and produces fungible units across all issuances, + enabling flexible supply strategies while maintaining cryptographic coherence. +reviewed: false diff --git a/courses/csv404/quizz/041/question.yml b/courses/csv404/quizz/041/question.yml new file mode 100644 index 00000000000..ab7940f6947 --- /dev/null +++ b/courses/csv404/quizz/041/question.yml @@ -0,0 +1,7 @@ +id: 0e0d39ff-c201-46e5-a76c-14e849825a26 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/042/en.yml b/courses/csv404/quizz/042/en.yml new file mode 100644 index 00000000000..770b7baaf65 --- /dev/null +++ b/courses/csv404/quizz/042/en.yml @@ -0,0 +1,12 @@ +question: Which TAPD API service is responsible for asset discovery, synchronization, and proof distribution? +answer: UniverseService +wrong_answers: + - TaprootAssetService + - AssetWalletService + - MintService +explanation: >- + TAPD exposes four distinct API services. The UniverseService handles asset + discovery, synchronization, and proof distribution. TaprootAssetService covers + core protocol operations like transfers and address generation, AssetWalletService + manages wallet operations, and MintService handles asset creation and batch management. +reviewed: false diff --git a/courses/csv404/quizz/042/question.yml b/courses/csv404/quizz/042/question.yml new file mode 100644 index 00000000000..206e55519eb --- /dev/null +++ b/courses/csv404/quizz/042/question.yml @@ -0,0 +1,7 @@ +id: 015d2be5-4314-4adc-a5ef-76627898526d +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/043/en.yml b/courses/csv404/quizz/043/en.yml new file mode 100644 index 00000000000..e1a4d1a722b --- /dev/null +++ b/courses/csv404/quizz/043/en.yml @@ -0,0 +1,13 @@ +question: In the dual PSBT architecture, what is the role of the virtual PSBT (vPSBT)? +answer: It carries asset-specific data such as Merkle tree updates and proof info for coordination between TAPD nodes +wrong_answers: + - It creates the final on-chain Bitcoin transaction that contains the new asset commitments and all change outputs + - It handles the signing of Bitcoin inputs and outputs for the underlying base layer transaction directly + - It broadcasts the finalized transaction to the Bitcoin network for miner inclusion and confirmation checks +explanation: >- + The dual PSBT architecture separates concerns into two layers. The virtual PSBT + (vPSBT) extends the standard PSBT format with custom fields for asset-level + coordination, carrying data like Merkle tree updates, proof information, and + commitment details. The anchor PSBT then handles what happens on the blockchain + by producing the actual on-chain Bitcoin transaction. +reviewed: false diff --git a/courses/csv404/quizz/043/question.yml b/courses/csv404/quizz/043/question.yml new file mode 100644 index 00000000000..2cd8302f2e0 --- /dev/null +++ b/courses/csv404/quizz/043/question.yml @@ -0,0 +1,7 @@ +id: ba242044-2297-466b-94ce-5b4a647a40c0 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/044/en.yml b/courses/csv404/quizz/044/en.yml new file mode 100644 index 00000000000..258459728d4 --- /dev/null +++ b/courses/csv404/quizz/044/en.yml @@ -0,0 +1,13 @@ +question: Why is the dual PSBT architecture advantageous for developers integrating Taproot Assets? +answer: Existing Bitcoin libraries handle the anchor PSBT unmodified while asset logic layers on top via the virtual PSBT +wrong_answers: + - It eliminates the need for any on-chain transactions entirely by handling everything through virtual transactions alone + - It allows developers to bypass LND entirely and interact directly with Bitcoin Core for all asset operations + - It reduces the number of cryptographic signatures required per transaction down to a single aggregated signature +explanation: >- + The key developer advantage of the dual PSBT architecture is backward compatibility. + The anchor PSBT is a standard Bitcoin PSBT that any existing Bitcoin library can + process without modification. The virtual PSBT adds asset-specific coordination + on top, meaning developers do not need to replace their existing Bitcoin tooling + to work with Taproot Assets. +reviewed: false diff --git a/courses/csv404/quizz/044/question.yml b/courses/csv404/quizz/044/question.yml new file mode 100644 index 00000000000..5c40aa3d1ac --- /dev/null +++ b/courses/csv404/quizz/044/question.yml @@ -0,0 +1,7 @@ +id: 66c6749e-b44f-4044-92d8-1f2aa2a24668 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/045/en.yml b/courses/csv404/quizz/045/en.yml new file mode 100644 index 00000000000..26d7deee370 --- /dev/null +++ b/courses/csv404/quizz/045/en.yml @@ -0,0 +1,12 @@ +question: Which of the following is one of the four roles that a universe serves in the Taproot Assets ecosystem? +answer: It acts as a proof repository, storing and serving cryptographic proofs for asset operations +wrong_answers: + - It functions as a mining pool that processes asset transactions and confirms them on-chain + - It operates as a custodial wallet that holds asset balances on behalf of its users + - It serves as a consensus engine that validates asset rules independently from Bitcoin consensus +explanation: >- + A universe serves four simultaneous roles: virtual mempool (tracking pending + operations), explorer (browsing asset history), proof repository (storing and + serving cryptographic proofs), and transaction library (cataloguing completed + operations). It does not mine, custody assets, or run a separate consensus engine. +reviewed: false diff --git a/courses/csv404/quizz/045/question.yml b/courses/csv404/quizz/045/question.yml new file mode 100644 index 00000000000..ece8ab91764 --- /dev/null +++ b/courses/csv404/quizz/045/question.yml @@ -0,0 +1,7 @@ +id: 75965f39-ab23-4835-a893-2ae56199f9b0 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/046/en.yml b/courses/csv404/quizz/046/en.yml new file mode 100644 index 00000000000..8177b8506dc --- /dev/null +++ b/courses/csv404/quizz/046/en.yml @@ -0,0 +1,13 @@ +question: How does the federation model in Taproot Assets handle trust and data sourcing? +answer: Each client defines its own federation of trusted universe servers from which it accepts asset data and proofs +wrong_answers: + - A central authority designates official federation members that all clients must connect to and trust implicitly + - Federation membership is determined by a proof-of-stake mechanism among competing universe operators globally + - All universe servers automatically join a single global federation with mandatory synchronization of every proof +explanation: >- + The federation model is client-defined rather than centrally imposed. Each client + chooses its own set of trusted universe servers, creating a personalized federation. + Members of a federation periodically synchronize, exchanging information about new + assets and transfers, providing redundancy and data availability while preserving + user sovereignty over information sources. +reviewed: false diff --git a/courses/csv404/quizz/046/question.yml b/courses/csv404/quizz/046/question.yml new file mode 100644 index 00000000000..cd7905c8816 --- /dev/null +++ b/courses/csv404/quizz/046/question.yml @@ -0,0 +1,7 @@ +id: 9b06b416-fa8b-49af-a32c-c42e22f84b90 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/047/en.yml b/courses/csv404/quizz/047/en.yml new file mode 100644 index 00000000000..640d0f8b92d --- /dev/null +++ b/courses/csv404/quizz/047/en.yml @@ -0,0 +1,13 @@ +question: What verification steps are involved when using the universe API to confirm asset ownership? +answer: Checking signatures, validating Merkle tree structures, and confirming referenced Bitcoin transactions exist on-chain +wrong_answers: + - Querying a central certificate authority server and cross-referencing the asset against a global public registry entry + - Verifying the issuer's identity through KYC records and matching it against the on-chain asset metadata + - Decrypting the asset payload with the owner's public key and comparing it against the genesis block hash value +explanation: >- + Asset ownership verification through the universe API involves three cryptographic + checks: validating digital signatures to prove authorization, verifying Merkle tree + structures to confirm the asset's position in the commitment tree, and confirming + that the referenced Bitcoin transactions actually exist on the blockchain. These + steps provide trustless verification without relying on any central authority. +reviewed: false diff --git a/courses/csv404/quizz/047/question.yml b/courses/csv404/quizz/047/question.yml new file mode 100644 index 00000000000..9c95bd1a8f6 --- /dev/null +++ b/courses/csv404/quizz/047/question.yml @@ -0,0 +1,7 @@ +id: f7603abc-4b17-47a7-a268-1b66a8deeb13 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/048/en.yml b/courses/csv404/quizz/048/en.yml new file mode 100644 index 00000000000..a868d918623 --- /dev/null +++ b/courses/csv404/quizz/048/en.yml @@ -0,0 +1,13 @@ +question: How does Taproot Assets v0.2 reduce on-chain footprint when handling multiple assets? +answer: It embeds multiple different asset transfers together within the same Bitcoin transaction's outputs +wrong_answers: + - It compresses all asset data into a single OP_RETURN output storing a hash of all transfers + - It batches asset operations off-chain and settles one net summary transaction per day + - It uses a sidechain to process transfers and periodically anchors state to Bitcoin +explanation: >- + Taproot Assets v0.2 allows multiple asset types to be included within a single + Bitcoin transaction. Instead of requiring a separate on-chain transaction for each + asset operation, the protocol embeds multiple asset transfers within the same + transaction outputs. This significantly reduces the on-chain footprint while + preserving all security guarantees of the Bitcoin base layer. +reviewed: false diff --git a/courses/csv404/quizz/048/question.yml b/courses/csv404/quizz/048/question.yml new file mode 100644 index 00000000000..ce2a898857b --- /dev/null +++ b/courses/csv404/quizz/048/question.yml @@ -0,0 +1,7 @@ +id: c4d695fb-55cc-4a18-a9cc-55d79d918181 +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/049/en.yml b/courses/csv404/quizz/049/en.yml new file mode 100644 index 00000000000..9faf29bfa51 --- /dev/null +++ b/courses/csv404/quizz/049/en.yml @@ -0,0 +1,12 @@ +question: Through which two protocols are TAPD's API services accessible? +answer: gRPC for high-throughput applications and REST for standard HTTP integration +wrong_answers: + - WebSocket for real-time streaming and GraphQL for flexible data queries + - MQTT for lightweight messaging and SOAP for enterprise-grade service calls + - JSON-RPC for command-line interaction and Protocol Buffers for binary streaming +explanation: >- + TAPD exposes its four API services through two standard protocols: gRPC, which + is optimized for high-throughput programmatic applications, and REST, which + provides standard HTTP endpoints for broader integration compatibility. The API + documentation includes Python and JavaScript examples for common workflows. +reviewed: false diff --git a/courses/csv404/quizz/049/question.yml b/courses/csv404/quizz/049/question.yml new file mode 100644 index 00000000000..9834168b4e5 --- /dev/null +++ b/courses/csv404/quizz/049/question.yml @@ -0,0 +1,7 @@ +id: 0e369c04-3b88-4449-9d5f-01ebbf82858d +chapterId: c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/050/en.yml b/courses/csv404/quizz/050/en.yml new file mode 100644 index 00000000000..7fa0d4225fb --- /dev/null +++ b/courses/csv404/quizz/050/en.yml @@ -0,0 +1,12 @@ +question: What are the three foundational software components required before installing TAPD? +answer: Bitcoin Core (bitcoind), LND (Lightning Network Daemon), and the Go toolchain (version 1.21 or later) +wrong_answers: + - Bitcoin Core (bitcoind), Core Lightning (CLN), and Rust (version 1.70 or later) + - Bitcoin Core (bitcoind), Eclair, and Python (version 3.10 or later) + - Bitcoin Core (bitcoind), LND (Lightning Network Daemon), and Node.js (version 18 or later) +explanation: >- + TAPD requires three prerequisites: Bitcoin Core for the base layer blockchain + data, LND for Lightning Network functionality and key management, and Go + version 1.21 or later for compiling the TAPD source code. Earlier Go versions + will cause compilation errors. +reviewed: false diff --git a/courses/csv404/quizz/050/question.yml b/courses/csv404/quizz/050/question.yml new file mode 100644 index 00000000000..40f48d9f1d6 --- /dev/null +++ b/courses/csv404/quizz/050/question.yml @@ -0,0 +1,7 @@ +id: 3db5cddd-29ca-4847-b73c-ef501b89cb22 +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/051/en.yml b/courses/csv404/quizz/051/en.yml new file mode 100644 index 00000000000..3b7574a960f --- /dev/null +++ b/courses/csv404/quizz/051/en.yml @@ -0,0 +1,12 @@ +question: What two binaries does the TAPD compilation process produce? +answer: tapd (the main daemon) and tapcli (the command-line interface) +wrong_answers: + - tapd (the main daemon) and tapwallet (the built-in wallet manager) + - tapcli (the command-line interface) and tapserver (the REST API server) + - tapd (the main daemon) and tapproof (the proof verification utility) +explanation: >- + Running make install in the taproot-assets repository compiles two binaries + that are installed in the Go binary directory (typically $HOME/go/bin/): + tapd, which is the main Taproot Assets daemon, and tapcli, which is the + command-line interface for interacting with the daemon. +reviewed: false diff --git a/courses/csv404/quizz/051/question.yml b/courses/csv404/quizz/051/question.yml new file mode 100644 index 00000000000..eb1f37a4d95 --- /dev/null +++ b/courses/csv404/quizz/051/question.yml @@ -0,0 +1,7 @@ +id: c132dc17-5b27-48fa-a782-e35890c28aeb +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/052/en.yml b/courses/csv404/quizz/052/en.yml new file mode 100644 index 00000000000..b14692a5137 --- /dev/null +++ b/courses/csv404/quizz/052/en.yml @@ -0,0 +1,13 @@ +question: What are the two security-critical file paths that must be correctly specified in the TAPD configuration? +answer: The LND TLS certificate path and the macaroon file path +wrong_answers: + - The Bitcoin Core RPC password file and the LND seed phrase backup + - The TAPD private key file and the Bitcoin Core wallet.dat path + - The SSL certificate for the REST API and the admin password hash file +explanation: >- + The TAPD configuration file requires two security-critical paths: + lnd.tlspath pointing to the TLS certificate and lnd.macaroonpath pointing + to the macaroon file. These provide the cryptographic credentials for + authenticated, encrypted communication between TAPD and LND. If either + path is incorrect, the daemon will refuse to start. +reviewed: false diff --git a/courses/csv404/quizz/052/question.yml b/courses/csv404/quizz/052/question.yml new file mode 100644 index 00000000000..305529c3ec5 --- /dev/null +++ b/courses/csv404/quizz/052/question.yml @@ -0,0 +1,7 @@ +id: c95ffef7-de65-43f2-a1b1-8d3e59fcca0d +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/053/en.yml b/courses/csv404/quizz/053/en.yml new file mode 100644 index 00000000000..6ad2af766c3 --- /dev/null +++ b/courses/csv404/quizz/053/en.yml @@ -0,0 +1,12 @@ +question: Why does the systemd service file for TAPD include both the After and Requires directives referencing lnd.service? +answer: To make TAPD wait for LND to start first and to declare LND a required dependency for TAPD +wrong_answers: + - To allow TAPD to share the same process space and memory pages as LND, reducing overhead + - To enable TAPD to automatically restart LND whenever LND crashes unexpectedly during runtime + - To merge the log outputs of both services into a single systemd journal entry for auditing +explanation: >- + The After=lnd.service directive ensures TAPD starts only after LND has finished + initializing, preventing race conditions at boot. The Requires=lnd.service directive + declares a hard dependency, meaning TAPD cannot run without LND. Together they + ensure correct startup ordering and dependency enforcement in production deployments. +reviewed: false diff --git a/courses/csv404/quizz/053/question.yml b/courses/csv404/quizz/053/question.yml new file mode 100644 index 00000000000..578ce1af9d1 --- /dev/null +++ b/courses/csv404/quizz/053/question.yml @@ -0,0 +1,7 @@ +id: 66aabbe5-d392-4f50-8524-08c2a4d8389b +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/054/en.yml b/courses/csv404/quizz/054/en.yml new file mode 100644 index 00000000000..df0ab040fbd --- /dev/null +++ b/courses/csv404/quizz/054/en.yml @@ -0,0 +1,13 @@ +question: What is the relationship between TAPD and private key management? +answer: TAPD never handles private keys itself; it delegates signing to LND, which relies on Bitcoin Core for chain data +wrong_answers: + - TAPD independently generates and stores its own private keys, kept separate from both LND and Bitcoin Core entirely + - TAPD imports private keys directly from Bitcoin Core and uses them for signing all asset transactions + - TAPD shares a single unified keystore with LND so that both daemons can sign transactions interchangeably +explanation: >- + TAPD operates on top of the LND and Bitcoin Core stack without ever handling + private keys directly. All signing operations are delegated to LND, which + manages its own key material. LND in turn relies on Bitcoin Core for on-chain + data. This separation of concerns ensures that TAPD does not introduce + additional key management attack surface. +reviewed: false diff --git a/courses/csv404/quizz/054/question.yml b/courses/csv404/quizz/054/question.yml new file mode 100644 index 00000000000..db073ae430d --- /dev/null +++ b/courses/csv404/quizz/054/question.yml @@ -0,0 +1,7 @@ +id: bb19d693-0620-448c-858d-58930689b958 +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/055/en.yml b/courses/csv404/quizz/055/en.yml new file mode 100644 index 00000000000..06949090f63 --- /dev/null +++ b/courses/csv404/quizz/055/en.yml @@ -0,0 +1,12 @@ +question: What are the default listening ports for TAPD's gRPC and REST interfaces? +answer: gRPC on port 10029 and REST on port 8089 +wrong_answers: + - gRPC on port 10009 and REST on port 8080 + - gRPC on port 9735 and REST on port 8443 + - gRPC on port 50051 and REST on port 3000 +explanation: >- + By default, TAPD listens on port 10029 for gRPC connections and port 8089 + for REST connections. These are distinct from LND's default ports (10009 + for gRPC). Knowing these ports is essential for configuring firewall rules + and for connecting client applications to the TAPD instance. +reviewed: false diff --git a/courses/csv404/quizz/055/question.yml b/courses/csv404/quizz/055/question.yml new file mode 100644 index 00000000000..18539e27aee --- /dev/null +++ b/courses/csv404/quizz/055/question.yml @@ -0,0 +1,7 @@ +id: 25a23f14-c6a9-4cc7-8b3a-35f7031f8d41 +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/056/en.yml b/courses/csv404/quizz/056/en.yml new file mode 100644 index 00000000000..443bebc7bb3 --- /dev/null +++ b/courses/csv404/quizz/056/en.yml @@ -0,0 +1,13 @@ +question: What is the correct order of the software stack on which TAPD operates, from the base layer upward? +answer: Bitcoin Core provides the base layer, LND provides the Lightning layer, and TAPD manages asset logic on top of both +wrong_answers: + - TAPD provides the base layer, Bitcoin Core provides blockchain anchoring, and LND provides routing services + - LND provides the base layer, TAPD provides the asset layer, and Bitcoin Core provides an indexing service only + - Bitcoin Core and LND operate as peers at the same layer, with TAPD coordinating between them as middleware +explanation: >- + The TAPD stack is a strict hierarchy. Bitcoin Core sits at the base, providing + on-chain data and blockchain access. LND operates on top of Bitcoin Core, + providing Lightning Network functionality and key management. TAPD sits at + the top, managing Taproot Asset logic and delegating all signing to LND. + This layered architecture means TAPD depends on both lower layers. +reviewed: false diff --git a/courses/csv404/quizz/056/question.yml b/courses/csv404/quizz/056/question.yml new file mode 100644 index 00000000000..f2f2dd9a163 --- /dev/null +++ b/courses/csv404/quizz/056/question.yml @@ -0,0 +1,7 @@ +id: f361667d-f701-45fb-8bab-70da394a33ee +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/057/en.yml b/courses/csv404/quizz/057/en.yml new file mode 100644 index 00000000000..0ff51f1378e --- /dev/null +++ b/courses/csv404/quizz/057/en.yml @@ -0,0 +1,12 @@ +question: Which LND version is required to support the latest TAPD releases, and what is the minimum version for TAPD v0.3? +answer: LND v0.20 or later is required for the latest TAPD releases, and LND v0.17 or greater is the minimum for TAPD v0.3 +wrong_answers: + - LND v0.18 or later is required for the latest TAPD releases, and LND v0.15 or greater is the minimum for TAPD v0.3 + - LND v0.21 or later is required for the latest TAPD releases, and LND v0.19 or greater is the minimum for TAPD v0.3 + - LND v0.17 or later is required for both the latest TAPD releases and TAPD v0.3, with no version distinction +explanation: >- + The course specifies that LND version 0.17 or greater is the minimum required + to support TAPD v0.3. However, for running the latest TAPD releases, LND v0.20 + or later is required. This version distinction is important because using an + incompatible LND version will prevent TAPD from functioning correctly. +reviewed: false diff --git a/courses/csv404/quizz/057/question.yml b/courses/csv404/quizz/057/question.yml new file mode 100644 index 00000000000..2f0fced9200 --- /dev/null +++ b/courses/csv404/quizz/057/question.yml @@ -0,0 +1,7 @@ +id: 60d7783d-55fa-4be4-bde3-522ee13d2c78 +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/058/en.yml b/courses/csv404/quizz/058/en.yml new file mode 100644 index 00000000000..cb84892baa7 --- /dev/null +++ b/courses/csv404/quizz/058/en.yml @@ -0,0 +1,13 @@ +question: What alternative installation methods exist besides compiling TAPD from source? +answer: Pre-built binaries from the Lightning Labs releases page, or Lightning Terminal (LitD), bundling TAPD with LND +wrong_answers: + - A Docker image officially maintained by Bitcoin Core, or installation via the Ubuntu apt manager + - A snap package available in the Canonical store, or a Homebrew formula for macOS-only users + - An npm package installable via Node.js, or a pip package that wraps the compiled Go binary +explanation: >- + Besides compiling from source, two alternatives are available. Pre-built binaries + from the Lightning Labs releases page eliminate the need for a Go toolchain. + Lightning Terminal (LitD) provides an even more integrated approach by bundling + TAPD alongside LND and several other services into a single package, which the + course covers in detail in a later chapter. +reviewed: false diff --git a/courses/csv404/quizz/058/question.yml b/courses/csv404/quizz/058/question.yml new file mode 100644 index 00000000000..30a236d7a74 --- /dev/null +++ b/courses/csv404/quizz/058/question.yml @@ -0,0 +1,7 @@ +id: 514b64ef-4f45-41d2-a51f-809271c22e75 +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/059/en.yml b/courses/csv404/quizz/059/en.yml new file mode 100644 index 00000000000..b515c3e8704 --- /dev/null +++ b/courses/csv404/quizz/059/en.yml @@ -0,0 +1,12 @@ +question: Where does TAPD look for its configuration file by default? +answer: In the .tapd directory located under the current user's home folder (e.g., ~/.tapd/tapd.conf) +wrong_answers: + - In the /etc/tapd/ system-wide configuration directory (e.g., /etc/tapd/tapd.conf) + - In the same directory as the tapd binary (e.g., $HOME/go/bin/tapd.conf) + - In the LND configuration directory alongside the lnd.conf file (e.g., ~/.lnd/tapd.conf) +explanation: >- + TAPD looks for its configuration file in the .tapd directory under the user's + home folder. The configuration file path is ~/.tapd/tapd.conf. While CLI flags + can be used to pass parameters at startup, a dedicated configuration file in + this location is the recommended approach for maintainability. +reviewed: false diff --git a/courses/csv404/quizz/059/question.yml b/courses/csv404/quizz/059/question.yml new file mode 100644 index 00000000000..8a5bdda475d --- /dev/null +++ b/courses/csv404/quizz/059/question.yml @@ -0,0 +1,7 @@ +id: 6bb3019d-74f0-498d-b5c0-f571783ae2c1 +chapterId: a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/060/en.yml b/courses/csv404/quizz/060/en.yml new file mode 100644 index 00000000000..e92a2a3e4ac --- /dev/null +++ b/courses/csv404/quizz/060/en.yml @@ -0,0 +1,12 @@ +question: What is Polar in the context of Taproot Assets development? +answer: A Docker-based desktop app for spinning up local Bitcoin and Lightning Network topologies for testing +wrong_answers: + - A cloud-hosted testnet service that provides shared Bitcoin and Lightning nodes for remote development + - A command-line tool that simulates Bitcoin transactions without running actual node software + - A browser-based IDE specifically designed for writing and debugging Taproot Assets smart contracts +explanation: >- + Polar is a Docker-based desktop application available for Mac, Windows, and Linux. + It allows developers to create complete local Bitcoin and Lightning Network + topologies with a few clicks, using the same software (Bitcoin Core, LND, TAPD) + that runs on mainnet. The only prerequisite is having Docker installed. +reviewed: false diff --git a/courses/csv404/quizz/060/question.yml b/courses/csv404/quizz/060/question.yml new file mode 100644 index 00000000000..8f2e9f20771 --- /dev/null +++ b/courses/csv404/quizz/060/question.yml @@ -0,0 +1,7 @@ +id: 0b698f79-501e-4662-9b4e-2da9e479bd52 +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/061/en.yml b/courses/csv404/quizz/061/en.yml new file mode 100644 index 00000000000..e8bfadddce3 --- /dev/null +++ b/courses/csv404/quizz/061/en.yml @@ -0,0 +1,12 @@ +question: What is the minimum network topology required for a functional TAPD development environment in Polar? +answer: At least 1 Bitcoin Core backend, at least 2 LND nodes, and 1 TAPD node paired to each LND node +wrong_answers: + - At least 2 Bitcoin Core backends, 1 LND node, and 1 TAPD node connected to both backends simultaneously + - At least 1 Bitcoin Core backend, 1 LND node, and 2 TAPD nodes sharing the same LND instance and macaroon + - At least 3 Bitcoin Core backends, 3 LND nodes, and 1 shared TAPD node for all Lightning nodes +explanation: >- + A functional TAPD development environment requires at least 1 Bitcoin Core backend + for blockchain operations, at least 2 LND nodes because testing transfers requires + two distinct endpoints, and 1 TAPD node per LND node, paired through Polar's + drag-and-drop interface. This gives you the sender and receiver needed for asset operations. +reviewed: false diff --git a/courses/csv404/quizz/061/question.yml b/courses/csv404/quizz/061/question.yml new file mode 100644 index 00000000000..e100047df6d --- /dev/null +++ b/courses/csv404/quizz/061/question.yml @@ -0,0 +1,7 @@ +id: 3ead2e26-87e8-4c7a-8032-d777cc99efdc +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/062/en.yml b/courses/csv404/quizz/062/en.yml new file mode 100644 index 00000000000..7aa461ce3dd --- /dev/null +++ b/courses/csv404/quizz/062/en.yml @@ -0,0 +1,12 @@ +question: Why is enabling auto-mining an essential configuration step in Polar before experimenting with TAPD? +answer: Because minting, sending, and burning all need on-chain confirmations, and auto-mining generates blocks automatically +wrong_answers: + - Because TAPD cannot establish a connection to LND unless a hundred blocks have already been mined on the network + - Because auto-mining generates the cryptographic zero-knowledge proofs that TAPD needs to validate asset ownership + - Because Polar's LND nodes require a minimum block height before they are able to open any new Lightning payment channels at all +explanation: >- + TAPD operations such as minting, sending, and burning assets all create on-chain + transactions that need block confirmations. Without auto-mining enabled, you would + have to manually trigger block creation each time. Auto-mining automates this + process so blocks are produced automatically, allowing seamless testing. +reviewed: false diff --git a/courses/csv404/quizz/062/question.yml b/courses/csv404/quizz/062/question.yml new file mode 100644 index 00000000000..1e41aa62d58 --- /dev/null +++ b/courses/csv404/quizz/062/question.yml @@ -0,0 +1,7 @@ +id: ccdc4c45-fce4-488f-b742-2945272a9a22 +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/063/en.yml b/courses/csv404/quizz/063/en.yml new file mode 100644 index 00000000000..bb905525299 --- /dev/null +++ b/courses/csv404/quizz/063/en.yml @@ -0,0 +1,13 @@ +question: What are the two distinct phases of the minting process when performing a test mint in TAPD? +answer: Batch creation (preparing data structures and cryptographic commitments) followed by batch finalization (embedding data into a Bitcoin transaction and confirming on-chain) +wrong_answers: + - Asset declaration (registering the asset with a universe server) followed by supply allocation (distributing units to initial holders across the federation network) + - Key generation (creating the asset-specific signing keys) followed by proof publication (broadcasting proofs to all federation members immediately after signing) + - Schema validation (checking asset metadata against protocol rules) followed by network propagation (distributing the asset to all connected nodes and peers) +explanation: >- + Minting in TAPD is a two-phase process. During batch creation, TAPD prepares all + necessary data structures and cryptographic commitments without writing anything + to the blockchain. During batch finalization, the prepared asset data is embedded + into a Bitcoin transaction and confirmed on-chain. In Polar, auto-mining handles + the confirmation automatically. +reviewed: false diff --git a/courses/csv404/quizz/063/question.yml b/courses/csv404/quizz/063/question.yml new file mode 100644 index 00000000000..175428f09b9 --- /dev/null +++ b/courses/csv404/quizz/063/question.yml @@ -0,0 +1,7 @@ +id: 3bca1dda-1dc6-4bcb-8e2b-e318cf023608 +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/064/en.yml b/courses/csv404/quizz/064/en.yml new file mode 100644 index 00000000000..f176494dbc2 --- /dev/null +++ b/courses/csv404/quizz/064/en.yml @@ -0,0 +1,13 @@ +question: Why does asset minting in Polar require that nodes be funded with bitcoin before proceeding? +answer: Because asset minting creates on-chain transactions that consume bitcoin for transaction fees +wrong_answers: + - Because the minted asset's value is derived from the amount of bitcoin locked in the funding transaction + - Because TAPD requires a bitcoin collateral deposit that is returned after the asset is successfully created + - Because Polar uses a proof-of-stake mechanism where bitcoin holdings determine minting priority +explanation: >- + Asset minting in TAPD produces on-chain Bitcoin transactions that require + transaction fees paid in bitcoin. Without funded nodes, these transactions + cannot be created. Polar provides built-in funding mechanisms that generate + testnet balances automatically, but nodes must be funded before any minting + operation can proceed. +reviewed: false diff --git a/courses/csv404/quizz/064/question.yml b/courses/csv404/quizz/064/question.yml new file mode 100644 index 00000000000..af78e188f12 --- /dev/null +++ b/courses/csv404/quizz/064/question.yml @@ -0,0 +1,7 @@ +id: 5cf0b685-faf2-49e8-9e2f-bd3a4fc8059f +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/065/en.yml b/courses/csv404/quizz/065/en.yml new file mode 100644 index 00000000000..bdcd6e7d591 --- /dev/null +++ b/courses/csv404/quizz/065/en.yml @@ -0,0 +1,13 @@ +question: What authentication credentials does Polar automatically generate for each node's API access? +answer: TLS certificates and macaroon files required for secure REST and gRPC communication +wrong_answers: + - OAuth2 access tokens and refresh tokens that automatically expire after 24 hours of inactivity + - A plaintext username and password pair stored in the node's local configuration file + - SSH key pairs and GPG signatures used for encrypted peer-to-peer node communication +explanation: >- + Each node in Polar automatically generates TLS certificates and macaroon files, + which are the same authentication credentials used in production TAPD deployments. + These credentials enable secure, authenticated communication via both REST and + gRPC interfaces. They can be found in each node's detail panel within the + Polar interface. +reviewed: false diff --git a/courses/csv404/quizz/065/question.yml b/courses/csv404/quizz/065/question.yml new file mode 100644 index 00000000000..a4fb0bf3a4b --- /dev/null +++ b/courses/csv404/quizz/065/question.yml @@ -0,0 +1,7 @@ +id: 3b6cfd2c-81a6-4abf-b0eb-f771719d38b8 +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/066/en.yml b/courses/csv404/quizz/066/en.yml new file mode 100644 index 00000000000..aec382c205c --- /dev/null +++ b/courses/csv404/quizz/066/en.yml @@ -0,0 +1,13 @@ +question: How can you verify that a successful mint occurred in Polar after batch finalization and block confirmation? +answer: Query the node's asset list and confirm it shows a populated result where it was empty before minting +wrong_answers: + - Check the Bitcoin Core debug log for a special TAPD_MINT_SUCCESS flag appended to the coinbase transaction + - Inspect the LND channel database for a new virtual channel entry corresponding to the minted asset + - Verify that the TAPD node's REST endpoint returns a 200 status code when queried for the genesis block +explanation: >- + After finalization and block confirmation, querying the TAPD node's asset list + should show the newly minted asset. An empty result before minting and a + populated result afterward confirms that the entire stack, from Bitcoin Core + through LND to TAPD, is functioning correctly. This is the recommended + verification method described in the course. +reviewed: false diff --git a/courses/csv404/quizz/066/question.yml b/courses/csv404/quizz/066/question.yml new file mode 100644 index 00000000000..81b55aa4b7b --- /dev/null +++ b/courses/csv404/quizz/066/question.yml @@ -0,0 +1,7 @@ +id: fda837f9-bbe8-45f6-9272-b7966bb24a24 +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/067/en.yml b/courses/csv404/quizz/067/en.yml new file mode 100644 index 00000000000..77100450a10 --- /dev/null +++ b/courses/csv404/quizz/067/en.yml @@ -0,0 +1,13 @@ +question: Why does everything learned in Polar translate directly to production environments? +answer: Because Polar uses the same software that runs on mainnet (Bitcoin Core, LND, TAPD), just in a local Docker environment +wrong_answers: + - Because Polar connects directly to the Bitcoin testnet, which uses identical consensus rules and network parameters as mainnet + - Because Polar simulates mainnet network conditions by introducing artificial latency and realistic fee market dynamics + - Because Polar's custom TAPD fork is deliberately designed to behave identically to the production version in all edge cases +explanation: >- + Polar runs the exact same Bitcoin Core, LND, and TAPD software that operates on + mainnet, packaged as Docker containers in a local environment. This means the + APIs, configuration, and behavior are identical to production. The only differences + are the local network context, on-demand block generation, and the absence of + real economic value. +reviewed: false diff --git a/courses/csv404/quizz/067/question.yml b/courses/csv404/quizz/067/question.yml new file mode 100644 index 00000000000..35e01b4f866 --- /dev/null +++ b/courses/csv404/quizz/067/question.yml @@ -0,0 +1,7 @@ +id: 6279ff10-030c-4700-bd33-eccce7701a7f +chapterId: d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/070/en.yml b/courses/csv404/quizz/070/en.yml new file mode 100644 index 00000000000..2fc592ab8d9 --- /dev/null +++ b/courses/csv404/quizz/070/en.yml @@ -0,0 +1,9 @@ +question: "How many services does Lightning Terminal (LitD) bundle into a single binary?" +answer: "Five: LND, TAPD, Loop, Pool, and Faraday" +wrong_answers: + - "Three: LND, TAPD, and Loop" + - "Four: LND, TAPD, Loop, and Pool" + - "Six: LND, TAPD, Loop, Pool, Faraday, and Neutrino" +explanation: >- + LitD bundles exactly five services: LND for Lightning Network operations, TAPD for Taproot Assets, Loop for submarine swaps, Pool for the Lightning channel liquidity marketplace, and Faraday for channel analytics and recommendations. This integrated approach eliminates the complexity of managing separate installations for each service. +reviewed: false diff --git a/courses/csv404/quizz/070/question.yml b/courses/csv404/quizz/070/question.yml new file mode 100644 index 00000000000..0df852bd71a --- /dev/null +++ b/courses/csv404/quizz/070/question.yml @@ -0,0 +1,7 @@ +id: "8c2672ba-87d4-45a9-ab08-d203e953f36e" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/071/en.yml b/courses/csv404/quizz/071/en.yml new file mode 100644 index 00000000000..0cad6bff3aa --- /dev/null +++ b/courses/csv404/quizz/071/en.yml @@ -0,0 +1,9 @@ +question: "Which three tools are required to build LitD from source?" +answer: "Go, Node.js, and Yarn" +wrong_answers: + - "Go, Python, and npm" + - "Rust, Node.js, and Yarn" + - "Go, Node.js, and Docker" +explanation: >- + Building LitD from source requires Go, Node.js, and Yarn. All three must be installed before cloning the repository and running the compilation. The build process uses a single 'make install' command to compile LitD along with all bundled services. +reviewed: false diff --git a/courses/csv404/quizz/071/question.yml b/courses/csv404/quizz/071/question.yml new file mode 100644 index 00000000000..2143c0f8f53 --- /dev/null +++ b/courses/csv404/quizz/071/question.yml @@ -0,0 +1,7 @@ +id: "cdb756f1-573a-4e12-860b-a38610122198" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: easy +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/072/en.yml b/courses/csv404/quizz/072/en.yml new file mode 100644 index 00000000000..1f9e5a90cee --- /dev/null +++ b/courses/csv404/quizz/072/en.yml @@ -0,0 +1,9 @@ +question: "What does the 'lnd-mode=integrated' setting in lit.conf accomplish?" +answer: "It tells LitD to manage LND internally rather than connecting to an external instance" +wrong_answers: + - "It configures LND to run in a lightweight mode with reduced memory usage and disk footprint" + - "It enables LND to accept incoming connections from external Taproot Assets daemons directly" + - "It instructs LitD to use a remote LND node over the network instead of a local one" +explanation: >- + The 'lnd-mode=integrated' setting in lit.conf tells LitD to manage its own internal LND instance. This means LND runs as part of the LitD process itself, eliminating the need to install, configure, and maintain a separate standalone LND daemon. This is one of the key advantages of the integrated LitD approach. +reviewed: false diff --git a/courses/csv404/quizz/072/question.yml b/courses/csv404/quizz/072/question.yml new file mode 100644 index 00000000000..a8453a9d734 --- /dev/null +++ b/courses/csv404/quizz/072/question.yml @@ -0,0 +1,7 @@ +id: "75a827ad-7143-4057-9e2e-bae6d6c961bd" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: easy +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/073/en.yml b/courses/csv404/quizz/073/en.yml new file mode 100644 index 00000000000..2a198c65b1c --- /dev/null +++ b/courses/csv404/quizz/073/en.yml @@ -0,0 +1,9 @@ +question: "Where does LitD read its configuration file from by default?" +answer: "~/.lit/lit.conf" +wrong_answers: + - "~/.lnd/litd.conf" + - "/etc/litd/lit.conf" + - "~/.tapd/lit.conf" +explanation: >- + LitD reads its configuration from ~/.lit/lit.conf. This is a dedicated directory for LitD configuration, separate from the directories used by standalone LND (~/.lnd) or TAPD (~/.tapd). The directory must be created before writing the configuration file using 'mkdir -p ~/.lit'. +reviewed: false diff --git a/courses/csv404/quizz/073/question.yml b/courses/csv404/quizz/073/question.yml new file mode 100644 index 00000000000..c14ae394e6b --- /dev/null +++ b/courses/csv404/quizz/073/question.yml @@ -0,0 +1,7 @@ +id: "50bf9ea3-9ac3-43a9-854e-0a7f33a79254" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: easy +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/074/en.yml b/courses/csv404/quizz/074/en.yml new file mode 100644 index 00000000000..d4002a95e46 --- /dev/null +++ b/courses/csv404/quizz/074/en.yml @@ -0,0 +1,9 @@ +question: "How does LitD's systemd unit dependency differ from a standalone TAPD systemd configuration?" +answer: "LitD depends on bitcoind only, since LND is bundled inside LitD" +wrong_answers: + - "LitD depends on both bitcoind and lnd services, just like standalone TAPD" + - "LitD has no systemd dependencies because it manages all services internally" + - "LitD depends on lnd.service only, since Bitcoin Core is optional with Neutrino" +explanation: >- + A standalone TAPD systemd unit depends on a separate LND service, but LitD bundles LND internally. Therefore, LitD's systemd unit only needs to declare a dependency on bitcoind.service. LitD still requires a Bitcoin backend, so the bitcoind dependency remains necessary for proper startup ordering. +reviewed: false diff --git a/courses/csv404/quizz/074/question.yml b/courses/csv404/quizz/074/question.yml new file mode 100644 index 00000000000..d548b823e97 --- /dev/null +++ b/courses/csv404/quizz/074/question.yml @@ -0,0 +1,7 @@ +id: "7fb0d6ca-9739-41c6-86f5-59e58306c2c3" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: hard +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/075/en.yml b/courses/csv404/quizz/075/en.yml new file mode 100644 index 00000000000..a018b617fb9 --- /dev/null +++ b/courses/csv404/quizz/075/en.yml @@ -0,0 +1,9 @@ +question: "What is the trade-off of using Neutrino instead of Bitcoin Core as LitD's backend?" +answer: "Neutrino does not require a full node but offers reduced privacy and verification guarantees" +wrong_answers: + - "Neutrino provides stronger privacy but requires significantly more disk space than Bitcoin Core" + - "Neutrino offers the same verification guarantees but cannot be used on testnet" + - "Neutrino requires a full node but provides faster initial synchronization times" +explanation: >- + Neutrino is a lighter-weight alternative to Bitcoin Core that relies on compact block filters instead of downloading and validating the full blockchain. While this eliminates the need to run a full node, it comes with trade-offs in privacy and verification guarantees because the node depends on third-party servers for block filter data rather than validating everything independently. +reviewed: false diff --git a/courses/csv404/quizz/075/question.yml b/courses/csv404/quizz/075/question.yml new file mode 100644 index 00000000000..0b430dc319a --- /dev/null +++ b/courses/csv404/quizz/075/question.yml @@ -0,0 +1,7 @@ +id: "c3bc5876-4959-49ce-8473-f59744d38f25" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: hard +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/076/en.yml b/courses/csv404/quizz/076/en.yml new file mode 100644 index 00000000000..ccf8b967649 --- /dev/null +++ b/courses/csv404/quizz/076/en.yml @@ -0,0 +1,9 @@ +question: "In LitD's lit.conf for a testnet Bitcoin Core backend, which ZMQ endpoints must be configured?" +answer: "zmqpubrawblock and zmqpubrawtx, both pointing to the local Bitcoin Core instance" +wrong_answers: + - "zmqpubhashblock and zmqpubhashtx, both pointing to the local Bitcoin Core instance" + - "zmqpubrawblock only, since LitD derives transaction data from raw blocks internally" + - "zmqpubrawblock, zmqpubrawtx, and zmqpubsequence for proper chain state tracking" +explanation: >- + The lit.conf configuration requires two ZMQ endpoints: bitcoind.zmqpubrawblock for raw block notifications and bitcoind.zmqpubrawtx for raw transaction notifications. These are the standard ZMQ topics that LND (bundled within LitD) uses to receive real-time blockchain data from Bitcoin Core. The hash-based variants (hashblock/hashtx) are different ZMQ topics and would not provide the full data LND requires. +reviewed: false diff --git a/courses/csv404/quizz/076/question.yml b/courses/csv404/quizz/076/question.yml new file mode 100644 index 00000000000..210c24c4063 --- /dev/null +++ b/courses/csv404/quizz/076/question.yml @@ -0,0 +1,7 @@ +id: "1468681a-8cd2-4dfc-a8d4-55d848d1c7f9" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/077/en.yml b/courses/csv404/quizz/077/en.yml new file mode 100644 index 00000000000..37e835f3da3 --- /dev/null +++ b/courses/csv404/quizz/077/en.yml @@ -0,0 +1,9 @@ +question: "How can automatic wallet unlocking be enabled in a production LitD deployment?" +answer: "By storing the wallet password in a secure file and referencing it via lnd.wallet-unlock-password-file" +wrong_answers: + - "By passing the wallet password as a plaintext command-line argument when starting the litd binary directly" + - "By setting the LND_WALLET_PASSWORD environment variable before starting the LitD process each time" + - "By configuring the systemd unit file with an Environment directive containing the raw wallet password" +explanation: >- + For production environments, LitD supports automatic wallet unlocking by referencing a password file in the configuration. The setting lnd.wallet-unlock-password-file=/path/to/password.txt in lit.conf allows LitD to unlock the LND wallet automatically on startup without manual intervention. This avoids storing passwords in environment variables or command-line arguments, which would be visible in process listings. +reviewed: false diff --git a/courses/csv404/quizz/077/question.yml b/courses/csv404/quizz/077/question.yml new file mode 100644 index 00000000000..6b8c8cb0b76 --- /dev/null +++ b/courses/csv404/quizz/077/question.yml @@ -0,0 +1,7 @@ +id: "0527e16d-226c-4c08-ad8a-900b019b2373" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/078/en.yml b/courses/csv404/quizz/078/en.yml new file mode 100644 index 00000000000..d67290ca09b --- /dev/null +++ b/courses/csv404/quizz/078/en.yml @@ -0,0 +1,9 @@ +question: "Which command is used to verify that all bundled services within LitD are operational?" +answer: "litcli status" +wrong_answers: + - "lncli status" + - "litd status" + - "tapd status" +explanation: >- + The 'litcli status' command displays the state of every service bundled within LitD. It shows whether LND, TAPD, Loop, Pool, and Faraday are all reporting as active (SERVER_ACTIVE). While 'lncli getinfo' would only check the LND component, 'litcli status' provides a unified view of all five services from the LitD-specific CLI tool. +reviewed: false diff --git a/courses/csv404/quizz/078/question.yml b/courses/csv404/quizz/078/question.yml new file mode 100644 index 00000000000..1ddd2c53dcb --- /dev/null +++ b/courses/csv404/quizz/078/question.yml @@ -0,0 +1,7 @@ +id: "9a44c027-5abb-4bf8-98e1-8ba8d77244b9" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: easy +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/079/en.yml b/courses/csv404/quizz/079/en.yml new file mode 100644 index 00000000000..6b9acebe983 --- /dev/null +++ b/courses/csv404/quizz/079/en.yml @@ -0,0 +1,9 @@ +question: "What is the purpose of the 'lncli create' command when first starting LitD?" +answer: "It creates a new wallet and generates a seed phrase for backup and recovery" +wrong_answers: + - "It initializes the LitD configuration file and creates required directories" + - "It creates a new Lightning channel with a default peer for initial connectivity" + - "It registers the node with the Lightning Network and assigns a public key" +explanation: >- + On first startup, LitD requires wallet creation through the 'lncli create' command. This generates a seed phrase that serves as the ultimate backup for the wallet, allowing restoration of the wallet and all associated funds. The seed phrase must be recorded securely as it is the only way to recover the wallet if the node is lost. +reviewed: false diff --git a/courses/csv404/quizz/079/question.yml b/courses/csv404/quizz/079/question.yml new file mode 100644 index 00000000000..7087d9f4b8e --- /dev/null +++ b/courses/csv404/quizz/079/question.yml @@ -0,0 +1,7 @@ +id: "04e38d56-b38f-4736-a212-fcb0806063ce" +chapterId: "b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43" +difficulty: intermediate +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/080/en.yml b/courses/csv404/quizz/080/en.yml new file mode 100644 index 00000000000..88854cb616a --- /dev/null +++ b/courses/csv404/quizz/080/en.yml @@ -0,0 +1,9 @@ +question: "What is a universe in the Taproot Assets ecosystem?" +answer: "A data store holding asset proofs and metadata, acting like a specialized block explorer for Taproot Assets" +wrong_answers: + - "A consensus mechanism that validates Taproot Asset transactions across the Lightning Network's routing nodes" + - "A smart contract runtime environment that executes asset transfer logic directly on the Bitcoin blockchain layer" + - "A peer-to-peer network protocol that replaces the need for Lightning channels in asset transfer settlement" +explanation: >- + A universe is a data store that holds asset proofs and metadata. It functions like a block explorer but specialized for Taproot Assets, storing the off-chain proof data that TAP clients need to discover, verify, and transfer assets. It can be compared to a Git repository, but for asset proofs rather than code. +reviewed: false diff --git a/courses/csv404/quizz/080/question.yml b/courses/csv404/quizz/080/question.yml new file mode 100644 index 00000000000..58f841b7af2 --- /dev/null +++ b/courses/csv404/quizz/080/question.yml @@ -0,0 +1,7 @@ +id: "ac21e6a4-664c-4d8e-8e10-68d198fe4839" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/081/en.yml b/courses/csv404/quizz/081/en.yml new file mode 100644 index 00000000000..68d130e1083 --- /dev/null +++ b/courses/csv404/quizz/081/en.yml @@ -0,0 +1,9 @@ +question: "What is a federation in the context of Taproot Assets universes?" +answer: "A node's collection of trusted universe connections used to access and sync asset data from other sources" +wrong_answers: + - "A governance structure where multiple network nodes vote collectively on which assets are valid within the protocol" + - "A group of nodes that collectively sign every asset minting transaction using a shared multisig scheme" + - "A centralized registry that assigns unique identifiers to all Taproot Assets across the entire network" +explanation: >- + A federation refers to a node's collection of trusted universe connections. When nodes connect their universes to share data with each other, they form a federation. This allows nodes to discover, verify, and access asset proof data from multiple sources rather than relying solely on their own local universe store. +reviewed: false diff --git a/courses/csv404/quizz/081/question.yml b/courses/csv404/quizz/081/question.yml new file mode 100644 index 00000000000..1d922b12a95 --- /dev/null +++ b/courses/csv404/quizz/081/question.yml @@ -0,0 +1,7 @@ +id: "0580b0a3-542c-486a-8b45-a1e3f56b9cf8" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: intermediate +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/082/en.yml b/courses/csv404/quizz/082/en.yml new file mode 100644 index 00000000000..358c3a57b50 --- /dev/null +++ b/courses/csv404/quizz/082/en.yml @@ -0,0 +1,9 @@ +question: "Which command reveals all assets your universe has discovered through its federation connections?" +answer: "The `tapcli universe roots` command" +wrong_answers: + - "tapcli universe sync" + - "tapcli assets list" + - "tapcli universe federation list" +explanation: >- + The 'tapcli universe roots' command reveals all assets your universe has discovered through its federation connections. This is distinct from 'tapcli universe federation list', which shows the connected universe servers, and 'tapcli universe sync', which pulls the latest data. The 'tapcli assets list' command shows locally owned assets, not all discovered assets in the universe. +reviewed: false diff --git a/courses/csv404/quizz/082/question.yml b/courses/csv404/quizz/082/question.yml new file mode 100644 index 00000000000..63e05794410 --- /dev/null +++ b/courses/csv404/quizz/082/question.yml @@ -0,0 +1,7 @@ +id: "de4fcae6-f31a-4b5a-8b47-a742a11064ec" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: intermediate +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/083/en.yml b/courses/csv404/quizz/083/en.yml new file mode 100644 index 00000000000..4d724076517 --- /dev/null +++ b/courses/csv404/quizz/083/en.yml @@ -0,0 +1,9 @@ +question: "What happens to asset proof data when you mint an asset on a TAPD node?" +answer: "The proof data is automatically written to the node's local universe store" +wrong_answers: + - "The proof data is broadcast to all connected federation universes immediately" + - "The proof data is stored only in the Bitcoin blockchain alongside the minting transaction" + - "The proof data is held in a temporary buffer until manually exported to a universe" +explanation: >- + Every TAPD node automatically includes its own local universe. When you mint an asset, the proof data is written to this local store automatically. The proof data does not automatically propagate to other universes in the federation; other nodes must sync with your universe to obtain it. The proof data itself is off-chain, not stored in the Bitcoin blockchain. +reviewed: false diff --git a/courses/csv404/quizz/083/question.yml b/courses/csv404/quizz/083/question.yml new file mode 100644 index 00000000000..ed08744be39 --- /dev/null +++ b/courses/csv404/quizz/083/question.yml @@ -0,0 +1,7 @@ +id: "b20d9442-08e3-44ba-a5d9-d9012e414516" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/084/en.yml b/courses/csv404/quizz/084/en.yml new file mode 100644 index 00000000000..088a1c28fea --- /dev/null +++ b/courses/csv404/quizz/084/en.yml @@ -0,0 +1,9 @@ +question: "When adding a universe via the REST API, which authentication credentials are required in the request?" +answer: The TLS certificate and the admin macaroon, both read from the TAPD data directory +wrong_answers: + - An API key generated from the TAPD web dashboard along with a signed session token + - The LND node's public key and a freshly signed authentication challenge string + - A username and password pair configured directly in the tapd.conf file settings +explanation: >- + REST API requests to TAPD require two credentials: the TLS certificate (--cacert ~/.tapd/tls.cert) for secure connection, and the admin macaroon passed as a Grpc-Metadata-macaroon header. The macaroon is read from ~/.tapd/data/testnet/admin.macaroon and hex-encoded using xxd. TAPD uses macaroon-based authentication, not API keys or username/password pairs. +reviewed: false diff --git a/courses/csv404/quizz/084/question.yml b/courses/csv404/quizz/084/question.yml new file mode 100644 index 00000000000..4fff4353f44 --- /dev/null +++ b/courses/csv404/quizz/084/question.yml @@ -0,0 +1,7 @@ +id: "95f0fbb0-4753-4d8c-b886-de484de338bc" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/085/en.yml b/courses/csv404/quizz/085/en.yml new file mode 100644 index 00000000000..cdef053ecea --- /dev/null +++ b/courses/csv404/quizz/085/en.yml @@ -0,0 +1,9 @@ +question: "According to the best practices for universe federation management, how should CLI and API be used?" +answer: "Use CLI for manual administration tasks and the REST or gRPC API for production automation workflows" +wrong_answers: + - "Use the CLI exclusively for all operations since the API is experimental and not yet production-ready" + - "Use the API for initial setup and configuration, then switch entirely to CLI for ongoing operations" + - "Use CLI only for read-only queries and restrict all write operations to the API for audit logging" +explanation: >- + The recommended best practice is to use CLI for administration and API for automation. Manual operations like adding or removing federation members are best done through tapcli, while production workflows that need programmatic control should use the REST or gRPC APIs. This separation keeps manual tasks simple while enabling scalable automation for production systems. +reviewed: false diff --git a/courses/csv404/quizz/085/question.yml b/courses/csv404/quizz/085/question.yml new file mode 100644 index 00000000000..969c01eaa90 --- /dev/null +++ b/courses/csv404/quizz/085/question.yml @@ -0,0 +1,7 @@ +id: "451c9377-3e85-4e06-b845-fc23d737ba5f" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/086/en.yml b/courses/csv404/quizz/086/en.yml new file mode 100644 index 00000000000..f5d99ccd267 --- /dev/null +++ b/courses/csv404/quizz/086/en.yml @@ -0,0 +1,9 @@ +question: "What is the REST API endpoint for adding a universe to a TAPD federation?" +answer: "POST to /v1/taproot-assets/universe/federation on port 8089 by default" +wrong_answers: + - "PUT to /v1/taproot-assets/universe/add on port 8080 by default" + - "POST to /v1/tap/federation/servers on port 10029 for RPC access" + - "POST to /v1/taproot-assets/universe/sync on port 8089 endpoint" +explanation: >- + The REST endpoint for adding a universe to a federation is a POST request to /v1/taproot-assets/universe/federation on port 8089 (the default TAPD REST port). The request body includes a 'servers' array with the host and id of the universe to add. This is distinct from the stats endpoint which uses a GET request to /v1/taproot-assets/universe/stats on the same port. +reviewed: false diff --git a/courses/csv404/quizz/086/question.yml b/courses/csv404/quizz/086/question.yml new file mode 100644 index 00000000000..7a8d049938f --- /dev/null +++ b/courses/csv404/quizz/086/question.yml @@ -0,0 +1,7 @@ +id: "3b8295dc-ef29-4ebe-8f00-f400afef0046" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: easy +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/087/en.yml b/courses/csv404/quizz/087/en.yml new file mode 100644 index 00000000000..af06ecd1024 --- /dev/null +++ b/courses/csv404/quizz/087/en.yml @@ -0,0 +1,9 @@ +question: "Why is the recommendation to 'curate rather than collect' important for universe federation management?" +answer: "Connecting to every available universe creates unnecessary network overhead without proportional benefit" +wrong_answers: + - "Connecting to too many universes causes consensus conflicts that can silently corrupt local asset proof data" + - "Each connected universe requires a separate on-chain Bitcoin transaction to maintain the active connection" + - "The Taproot Assets Protocol strictly limits each node to a maximum of ten federation connections total" +explanation: >- + The 'curate rather than collect' principle addresses a practical concern: connecting to every available universe creates unnecessary network overhead. Since each universe connection involves data synchronization, indiscriminate connections waste bandwidth and processing resources without adding value. Operators should connect only to universes that serve their specific needs, such as those hosting assets they care about. +reviewed: false diff --git a/courses/csv404/quizz/087/question.yml b/courses/csv404/quizz/087/question.yml new file mode 100644 index 00000000000..3bcf957d400 --- /dev/null +++ b/courses/csv404/quizz/087/question.yml @@ -0,0 +1,7 @@ +id: "14d25280-7def-4695-948c-10e672e6500b" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: hard +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/088/en.yml b/courses/csv404/quizz/088/en.yml new file mode 100644 index 00000000000..bbb9f10f9ed --- /dev/null +++ b/courses/csv404/quizz/088/en.yml @@ -0,0 +1,9 @@ +question: "What types of data does the universe stats API endpoint return?" +answer: "Asset awareness counts, synchronization status, and federation health metrics" +wrong_answers: + - "Individual asset transfer histories, sender and receiver addresses, and transaction fees" + - "Node uptime percentages, CPU utilization, and memory consumption statistics" + - "Lightning channel balances, routing fees earned, and payment success rates" +explanation: >- + The universe stats endpoint (/v1/taproot-assets/universe/stats) returns data about asset awareness (such as total assets discovered), synchronization status, and federation health. As shown in the course example, this includes metrics like total asset count, number of asset groups, and total proofs. It does not return individual transfer histories, node hardware metrics, or Lightning-specific financial data. +reviewed: false diff --git a/courses/csv404/quizz/088/question.yml b/courses/csv404/quizz/088/question.yml new file mode 100644 index 00000000000..422334b80a0 --- /dev/null +++ b/courses/csv404/quizz/088/question.yml @@ -0,0 +1,7 @@ +id: "65499d67-e4b9-4b00-87c9-4fa603375629" +chapterId: "e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/090/en.yml b/courses/csv404/quizz/090/en.yml new file mode 100644 index 00000000000..2901b220096 --- /dev/null +++ b/courses/csv404/quizz/090/en.yml @@ -0,0 +1,9 @@ +question: "What does minting a Taproot asset accomplish?" +answer: "It creates a brand-new asset by embedding asset data into a Bitcoin Taproot transaction" +wrong_answers: + - "It transfers an existing asset from one wallet to another through a Lightning payment" + - "It burns Bitcoin to produce a new token on a separate sidechain anchored to Bitcoin" + - "It registers an asset name in a global decentralized registry without any on-chain transaction" +explanation: >- + Minting is the act of creating brand-new assets on the Bitcoin blockchain. When you mint a Taproot asset, you embed asset data into a Bitcoin Taproot transaction, defining the asset's name, total supply, and whether additional units can be created. The result is a digital asset anchored to Bitcoin's proof-of-work security. +reviewed: false diff --git a/courses/csv404/quizz/090/question.yml b/courses/csv404/quizz/090/question.yml new file mode 100644 index 00000000000..ff2dbf8b4dd --- /dev/null +++ b/courses/csv404/quizz/090/question.yml @@ -0,0 +1,7 @@ +id: "89f8d121-759c-4082-9726-6b0323e68680" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/091/en.yml b/courses/csv404/quizz/091/en.yml new file mode 100644 index 00000000000..c166707f97b --- /dev/null +++ b/courses/csv404/quizz/091/en.yml @@ -0,0 +1,9 @@ +question: "What is the purpose of the batch system in the Taproot Assets minting workflow?" +answer: "It queues multiple asset creations to be finalized together in one on-chain transaction" +wrong_answers: + - "It splits a large minting operation across multiple transactions to avoid exceeding block size limits" + - "It groups assets by type so that fungible and collectible assets are minted on separate chains" + - "It enforces a mandatory waiting period between minting requests to prevent network congestion" +explanation: >- + The batch system queues pending asset creations so they can all be finalized in a single on-chain Bitcoin transaction. Since each minting transaction requires a mining fee, batching allows you to create multiple distinct assets while paying only one transaction fee. By default, tapcli places minting requests into a batch rather than broadcasting immediately. +reviewed: false diff --git a/courses/csv404/quizz/091/question.yml b/courses/csv404/quizz/091/question.yml new file mode 100644 index 00000000000..976fd9e9795 --- /dev/null +++ b/courses/csv404/quizz/091/question.yml @@ -0,0 +1,7 @@ +id: "76485ce4-fc91-40a4-9571-e71338fa0f08" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: intermediate +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/092/en.yml b/courses/csv404/quizz/092/en.yml new file mode 100644 index 00000000000..174c58e5d23 --- /dev/null +++ b/courses/csv404/quizz/092/en.yml @@ -0,0 +1,9 @@ +question: "What does the '--type normal' parameter specify when minting a Taproot asset?" +answer: "It creates a fungible asset, interchangeable unit for unit, as opposed to a collectible" +wrong_answers: + - "It creates a non-expandable asset with a permanently fixed total supply cap and locked metadata" + - "It mints the asset onto mainnet rather than testnet or signet by default configuration" + - "It creates the asset without encryption, so its metadata stays publicly visible on-chain" +explanation: >- + The '--type normal' parameter specifies that the asset being minted is fungible. In the Taproot Assets Protocol, 'normal' type assets are fungible, meaning each unit is interchangeable with any other unit of the same asset. The alternative type is 'collectible', which represents unique, non-fungible assets. The type parameter is about fungibility, not about supply expandability or network selection. +reviewed: false diff --git a/courses/csv404/quizz/092/question.yml b/courses/csv404/quizz/092/question.yml new file mode 100644 index 00000000000..09db2cf6870 --- /dev/null +++ b/courses/csv404/quizz/092/question.yml @@ -0,0 +1,7 @@ +id: "c2472d4e-3efd-492d-96e5-b252053a14fe" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: easy +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/093/en.yml b/courses/csv404/quizz/093/en.yml new file mode 100644 index 00000000000..e4fe1db41bc --- /dev/null +++ b/courses/csv404/quizz/093/en.yml @@ -0,0 +1,9 @@ +question: "What prerequisite must be met before a TAPD node can mint a Taproot asset?" +answer: "The TAPD node must be connected to an LND node with confirmed on-chain funds available" +wrong_answers: + - "The TAPD node must have at least one active Lightning channel with sufficient outbound liquidity" + - "The TAPD node must be synchronized with at least three universe federation servers" + - "The TAPD node must have registered its public key with the Taproot Assets genesis registry" +explanation: >- + Before minting, the TAPD node must be running and properly connected to an LND node that has confirmed on-chain funds. The minting transaction consumes a Bitcoin UTXO to anchor the new asset data into the blockchain. Lightning channels or universe federation connections are not prerequisites for the minting operation itself. +reviewed: false diff --git a/courses/csv404/quizz/093/question.yml b/courses/csv404/quizz/093/question.yml new file mode 100644 index 00000000000..dc481417add --- /dev/null +++ b/courses/csv404/quizz/093/question.yml @@ -0,0 +1,7 @@ +id: "d5eb172a-2a44-4f8c-af7a-00f2c064664e" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/094/en.yml b/courses/csv404/quizz/094/en.yml new file mode 100644 index 00000000000..1d245c9cb1d --- /dev/null +++ b/courses/csv404/quizz/094/en.yml @@ -0,0 +1,9 @@ +question: "What does the '--new_grouped_asset' flag accomplish during minting?" +answer: "It creates an asset group with a group key, letting future minting add new units to that asset" +wrong_answers: + - "It assigns the asset to a predefined category for organization within the local universe store" + - "It bundles the asset with other assets in the current batch so they share a single asset ID" + - "It enables the asset to be transferred across multiple Lightning channels simultaneously" +explanation: >- + The '--new_grouped_asset' flag (previously called '--enable_emission') creates an asset group with a group key during the initial mint. This group key can be referenced in future minting operations to add new units to the same asset, enabling expandable supply. Assets within the same group share a common group identifier and are fungible with one another, even if created in separate minting events. +reviewed: false diff --git a/courses/csv404/quizz/094/question.yml b/courses/csv404/quizz/094/question.yml new file mode 100644 index 00000000000..352f1858a28 --- /dev/null +++ b/courses/csv404/quizz/094/question.yml @@ -0,0 +1,7 @@ +id: "8d749ed9-1343-4d28-b076-072a7bc4af92" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/095/en.yml b/courses/csv404/quizz/095/en.yml new file mode 100644 index 00000000000..43442062c65 --- /dev/null +++ b/courses/csv404/quizz/095/en.yml @@ -0,0 +1,9 @@ +question: "How is a unique asset ID derived in the Taproot Assets Protocol?" +answer: "From the SHA-256 hash of the genesis outpoint, the asset tag, and the asset metadata" +wrong_answers: + - "From a random number generator seeded by the minting node's public key and a timestamp" + - "From the SHA-256 hash of the asset name, supply amount, and the minter's LND node ID" + - "From the RIPEMD-160 hash of the minting transaction ID and the asset's group key" +explanation: >- + Each Taproot asset is identified by a unique asset ID derived from the SHA-256 hash of three components: the genesis outpoint (the Bitcoin transaction output that anchored the creation), the asset tag, and the asset metadata. This deterministic derivation means any node can independently verify an asset's identity by recomputing the hash from these inputs. +reviewed: false diff --git a/courses/csv404/quizz/095/question.yml b/courses/csv404/quizz/095/question.yml new file mode 100644 index 00000000000..5e30ef1a451 --- /dev/null +++ b/courses/csv404/quizz/095/question.yml @@ -0,0 +1,7 @@ +id: "b4ec0b9d-3d67-4b81-a5c1-3501b07395f6" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/096/en.yml b/courses/csv404/quizz/096/en.yml new file mode 100644 index 00000000000..84b9d6e7e22 --- /dev/null +++ b/courses/csv404/quizz/096/en.yml @@ -0,0 +1,9 @@ +question: "What is the genesis outpoint in the context of a Taproot asset?" +answer: "The Bitcoin transaction output that anchored the asset's creation, a unique fingerprint to its birth" +wrong_answers: + - "The first Lightning channel through which the newly minted asset was transferred after minting" + - "The coinbase transaction of the block in which the asset's minting transaction was confirmed on-chain" + - "The initial UTXO that funded the minter's wallet before the minting transaction was ever broadcast" +explanation: >- + The genesis outpoint is the Bitcoin transaction output that anchored the asset's creation on the blockchain. It serves as the unique fingerprint that allows any node to trace the asset back to its exact moment of birth. It is one of the three inputs used to derive the asset ID via SHA-256 hashing. It is not the coinbase transaction of the block or the funding UTXO, but specifically the output of the minting transaction itself. +reviewed: false diff --git a/courses/csv404/quizz/096/question.yml b/courses/csv404/quizz/096/question.yml new file mode 100644 index 00000000000..61bd11d1450 --- /dev/null +++ b/courses/csv404/quizz/096/question.yml @@ -0,0 +1,7 @@ +id: "eef9d353-3e17-43f7-b71d-9f8d840740bc" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: easy +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/097/en.yml b/courses/csv404/quizz/097/en.yml new file mode 100644 index 00000000000..bed564080c8 --- /dev/null +++ b/courses/csv404/quizz/097/en.yml @@ -0,0 +1,9 @@ +question: "What are the two phases of the Taproot Assets minting workflow when using the batch system?" +answer: "Batch creation, where asset definitions are queued, followed by batch finalization, where TAPD broadcasts the anchoring transaction" +wrong_answers: + - "Asset registration, where the asset name is reserved in the universe, followed by asset confirmation, where the mining fee is paid" + - "Proof generation, where off-chain proofs are created locally, followed by proof distribution, where proofs are pushed to all federation universes" + - "Transaction drafting, where LND creates a raw Bitcoin transaction, followed by asset binding, where TAPD attaches asset metadata to the transaction" +explanation: >- + The minting workflow has two distinct phases. First, batch creation: you add one or more asset definitions to the pending batch using the 'tapcli assets mint' command. Second, batch finalization: you instruct TAPD to construct and broadcast the Bitcoin transaction that anchors all queued assets on-chain using 'tapcli assets mint finalize'. The --skip_batch flag combines both phases into a single step. +reviewed: false diff --git a/courses/csv404/quizz/097/question.yml b/courses/csv404/quizz/097/question.yml new file mode 100644 index 00000000000..f3fd9e52239 --- /dev/null +++ b/courses/csv404/quizz/097/question.yml @@ -0,0 +1,7 @@ +id: "1730a3d1-b76f-4b91-92f2-012ae56d6a38" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: hard +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/098/en.yml b/courses/csv404/quizz/098/en.yml new file mode 100644 index 00000000000..b1a64b9b246 --- /dev/null +++ b/courses/csv404/quizz/098/en.yml @@ -0,0 +1,9 @@ +question: "Why are assets minted within the same group considered fungible with one another?" +answer: "Because they share a common group identifier, making them fully interchangeable despite separate minting events" +wrong_answers: + - "Because they are all stored in the same Bitcoin UTXO, making them inseparable at the protocol level" + - "Because the protocol merges their genesis outpoints into a single combined proof after minting" + - "Because they inherit the same asset ID from the original mint, erasing distinction between batches" +explanation: >- + Assets minted within the same group share a common group identifier established by the group key created during the initial mint with '--new_grouped_asset'. This shared group identity is what makes them fungible with one another, even though each minting event produces assets with different genesis outpoints and occurs in a separate on-chain transaction. They do not share the same asset ID; rather, the group key establishes their mutual fungibility. +reviewed: false diff --git a/courses/csv404/quizz/098/question.yml b/courses/csv404/quizz/098/question.yml new file mode 100644 index 00000000000..011d23cd786 --- /dev/null +++ b/courses/csv404/quizz/098/question.yml @@ -0,0 +1,7 @@ +id: "26c0451a-2762-4775-bd16-b9cbb6766370" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: intermediate +duration: 45 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/099/en.yml b/courses/csv404/quizz/099/en.yml new file mode 100644 index 00000000000..fab462e9ee9 --- /dev/null +++ b/courses/csv404/quizz/099/en.yml @@ -0,0 +1,9 @@ +question: "What flag can be used to skip the batch system and mint an asset immediately?" +answer: "--skip_batch" +wrong_answers: + - "--force_mint" + - "--skip_queue" + - "--finalize" +explanation: >- + The '--skip_batch' flag can be appended to the 'tapcli assets mint' command to skip the batch system and finalize the minting transaction immediately. Without this flag, the minting request is placed into a pending batch that must be explicitly finalized later with 'tapcli assets mint finalize'. The skip_batch flag is a convenience for when you only want to mint a single asset. +reviewed: false diff --git a/courses/csv404/quizz/099/question.yml b/courses/csv404/quizz/099/question.yml new file mode 100644 index 00000000000..338ef0d3749 --- /dev/null +++ b/courses/csv404/quizz/099/question.yml @@ -0,0 +1,7 @@ +id: "a796e419-6d66-4569-948d-673727196b21" +chapterId: "f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76" +difficulty: easy +duration: 25 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/100/en.yml b/courses/csv404/quizz/100/en.yml new file mode 100644 index 00000000000..2a6b8d7350a --- /dev/null +++ b/courses/csv404/quizz/100/en.yml @@ -0,0 +1,9 @@ +question: "What are the two security elements required before making API calls to TAPD?" +answer: "The TLS certificate together with the admin macaroon file" +wrong_answers: + - "An API key paired with an OAuth access token" + - "A username-password pair and a session cookie" + - "An SSH keypair combined with a signed bearer token" +explanation: >- + TAPD's API security model requires two elements: the TLS certificate, which ensures encrypted communication between your application and the TAPD node, and the admin macaroon, which provides authentication and authorization for every API request. These are the same credentials used by the CLI but must be explicitly loaded and passed in API calls. +reviewed: false diff --git a/courses/csv404/quizz/100/question.yml b/courses/csv404/quizz/100/question.yml new file mode 100644 index 00000000000..65a33f60642 --- /dev/null +++ b/courses/csv404/quizz/100/question.yml @@ -0,0 +1,7 @@ +id: "ea7cc876-ba04-4f26-9302-973090d734ac" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/101/en.yml b/courses/csv404/quizz/101/en.yml new file mode 100644 index 00000000000..c49710de8e3 --- /dev/null +++ b/courses/csv404/quizz/101/en.yml @@ -0,0 +1,9 @@ +question: "How is the admin macaroon prepared for inclusion in API request headers?" +answer: "It is read as raw bytes and converted to a hexadecimal string" +wrong_answers: + - "It is read as a UTF-8 text file and passed directly as a string" + - "It is base64-encoded and included as a Bearer token" + - "It is hashed with SHA-256 and sent as a digest value" +explanation: >- + The admin macaroon file is read in binary mode and then converted to its hexadecimal representation using the .hex() method. This hex string is placed in the Grpc-Metadata-macaroon HTTP header. Reading it as text or encoding it differently would produce an invalid authentication token that TAPD would reject. +reviewed: false diff --git a/courses/csv404/quizz/101/question.yml b/courses/csv404/quizz/101/question.yml new file mode 100644 index 00000000000..ef81a8a7acf --- /dev/null +++ b/courses/csv404/quizz/101/question.yml @@ -0,0 +1,7 @@ +id: "4c3d262e-d8e7-494c-b260-d0ad42e7e424" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: intermediate +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/102/en.yml b/courses/csv404/quizz/102/en.yml new file mode 100644 index 00000000000..74057e34531 --- /dev/null +++ b/courses/csv404/quizz/102/en.yml @@ -0,0 +1,9 @@ +question: "What HTTP header name is used to pass the macaroon in TAPD API requests?" +answer: "Grpc-Metadata-macaroon" +wrong_answers: + - "Macaroon-Authorization" + - "X-Grpc-Macaroon-Token" + - "Grpc-Metadata-Auth-Token" +explanation: >- + The macaroon is passed via the Grpc-Metadata-macaroon header. This naming convention comes from gRPC metadata being tunneled through HTTP headers in the REST gateway. Using a standard Authorization header or an arbitrary custom header would not be recognized by the TAPD REST interface. +reviewed: false diff --git a/courses/csv404/quizz/102/question.yml b/courses/csv404/quizz/102/question.yml new file mode 100644 index 00000000000..3e0427d781b --- /dev/null +++ b/courses/csv404/quizz/102/question.yml @@ -0,0 +1,7 @@ +id: "24c42f9c-c659-4940-883d-b3ded54ecfe8" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: easy +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/103/en.yml b/courses/csv404/quizz/103/en.yml new file mode 100644 index 00000000000..4db962096ff --- /dev/null +++ b/courses/csv404/quizz/103/en.yml @@ -0,0 +1,9 @@ +question: "In the two-phase minting process via the API, what does Phase 1 accomplish?" +answer: "It adds an asset definition to the current minting batch" +wrong_answers: + - "It broadcasts the minting transaction to the Bitcoin network" + - "It generates the TLS certificate for secure minting" + - "It finalizes the batch and commits it to the blockchain" +explanation: >- + Phase 1 sends a POST request to the /v1/taproot-assets/assets/mint endpoint with the asset definition (type, name, amount), which adds the asset to the pending batch. The batch is not yet committed to the blockchain at this stage. Phase 2, the finalize step, is what actually triggers the on-chain transaction. +reviewed: false diff --git a/courses/csv404/quizz/103/question.yml b/courses/csv404/quizz/103/question.yml new file mode 100644 index 00000000000..23100bf4735 --- /dev/null +++ b/courses/csv404/quizz/103/question.yml @@ -0,0 +1,7 @@ +id: "622d6895-e252-4a79-be0b-f2d51347cf96" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/104/en.yml b/courses/csv404/quizz/104/en.yml new file mode 100644 index 00000000000..ddb682247a9 --- /dev/null +++ b/courses/csv404/quizz/104/en.yml @@ -0,0 +1,9 @@ +question: "What is the API endpoint used to finalize a minting batch?" +answer: "/v1/taproot-assets/assets/mint/finalize" +wrong_answers: + - "/v1/taproot-assets/assets/mint/commitment" + - "/v1/taproot-assets/assets/mint/finalized" + - "/v1/taproot-assets/mint/broadcast/status" +explanation: >- + The finalize endpoint is /v1/taproot-assets/assets/mint/finalize, called as a POST request with an empty JSON body. This endpoint triggers the on-chain commitment of all assets in the current batch. The other paths listed do not exist in the TAPD REST API specification. +reviewed: false diff --git a/courses/csv404/quizz/104/question.yml b/courses/csv404/quizz/104/question.yml new file mode 100644 index 00000000000..d7b2fdaf885 --- /dev/null +++ b/courses/csv404/quizz/104/question.yml @@ -0,0 +1,7 @@ +id: "321e3b1e-3fe7-4c10-acd7-662eba00cf00" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: easy +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/105/en.yml b/courses/csv404/quizz/105/en.yml new file mode 100644 index 00000000000..e264c288744 --- /dev/null +++ b/courses/csv404/quizz/105/en.yml @@ -0,0 +1,9 @@ +question: "What JSON body is sent to the finalize endpoint when completing a minting batch via the API?" +answer: "An empty JSON object, since TAPD already tracks the batch internally" +wrong_answers: + - "A JSON object containing the batch ID and a confirmation flag set to true" + - "A JSON object repeating the full asset definition submitted in Phase 1" + - "A JSON object specifying the target block height for the transaction" +explanation: >- + The finalize endpoint receives a POST request with an empty JSON body ({}). No additional parameters are needed because the batch to finalize is already held in TAPD's internal state from Phase 1. Including asset details or batch identifiers is unnecessary since TAPD tracks the pending batch automatically. +reviewed: false diff --git a/courses/csv404/quizz/105/question.yml b/courses/csv404/quizz/105/question.yml new file mode 100644 index 00000000000..a5c4e6eeea3 --- /dev/null +++ b/courses/csv404/quizz/105/question.yml @@ -0,0 +1,7 @@ +id: "ac388fc7-12fb-480f-a86d-b539756805cd" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: easy +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/106/en.yml b/courses/csv404/quizz/106/en.yml new file mode 100644 index 00000000000..b09a8aa7e04 --- /dev/null +++ b/courses/csv404/quizz/106/en.yml @@ -0,0 +1,9 @@ +question: "In the Python code example, why is the verify parameter set to cert_path in each API request?" +answer: "To validate the server's TLS certificate and ensure encrypted communication with the TAPD node" +wrong_answers: + - "To sign the request payload with the client's private key for non-repudiation purposes" + - "To attach the macaroon file path so the server can verify the requesting client's identity" + - "To enable HTTP/2 multiplexing which is strictly required by the gRPC-REST gateway proxy" +explanation: >- + The verify parameter in the Python requests library specifies the path to a CA certificate or a server certificate used to validate the TLS connection. This ensures the client communicates with the authentic TAPD node over an encrypted channel. It does not sign payloads or handle macaroon authentication, which is done separately through the headers. +reviewed: false diff --git a/courses/csv404/quizz/106/question.yml b/courses/csv404/quizz/106/question.yml new file mode 100644 index 00000000000..9a9f1f606e7 --- /dev/null +++ b/courses/csv404/quizz/106/question.yml @@ -0,0 +1,7 @@ +id: "a8df1275-a415-4526-845a-a3bf6c39c53e" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/107/en.yml b/courses/csv404/quizz/107/en.yml new file mode 100644 index 00000000000..f4e92060e70 --- /dev/null +++ b/courses/csv404/quizz/107/en.yml @@ -0,0 +1,9 @@ +question: "What HTTP method and endpoint are used to verify that minted assets exist after on-chain confirmation?" +answer: "A GET request to /v1/taproot-assets/assets, listing all assets" +wrong_answers: + - "A POST request to /v1/taproot-assets/assets/verify endpoint call" + - "A GET request to /v1/taproot-assets/assets/mint/status check" + - "A POST request to /v1/taproot-assets/assets/list, returns all" +explanation: >- + After on-chain confirmation, a GET request to /v1/taproot-assets/assets retrieves the full list of assets held by the node, allowing verification that the newly minted asset appears with the correct name and amount. This is a standard read operation, so it uses GET rather than POST. There is no separate verification or status endpoint for minted assets. +reviewed: false diff --git a/courses/csv404/quizz/107/question.yml b/courses/csv404/quizz/107/question.yml new file mode 100644 index 00000000000..ca5c417d284 --- /dev/null +++ b/courses/csv404/quizz/107/question.yml @@ -0,0 +1,7 @@ +id: "36246b3b-f6da-412c-b470-f3cb3745d968" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/108/en.yml b/courses/csv404/quizz/108/en.yml new file mode 100644 index 00000000000..9da91bb68ed --- /dev/null +++ b/courses/csv404/quizz/108/en.yml @@ -0,0 +1,9 @@ +question: "Which programming languages are covered in TAPD's official API documentation alongside the REST implementation?" +answer: "Python and JavaScript" +wrong_answers: + - "Go and Rust exclusively" + - "Java and C++ exclusively" + - "Ruby and TypeScript only" +explanation: >- + The TAPD API documentation at lightning.engineering covers both gRPC and REST implementations and provides examples in Python and JavaScript. While Go is the language TAPD itself is written in, the official API documentation examples specifically target Python and JavaScript for client-side integration. +reviewed: false diff --git a/courses/csv404/quizz/108/question.yml b/courses/csv404/quizz/108/question.yml new file mode 100644 index 00000000000..38149c98b01 --- /dev/null +++ b/courses/csv404/quizz/108/question.yml @@ -0,0 +1,7 @@ +id: "b45d10a3-c176-43fc-b9ef-ff249f4b66fd" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: easy +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/109/en.yml b/courses/csv404/quizz/109/en.yml new file mode 100644 index 00000000000..a0ffe275719 --- /dev/null +++ b/courses/csv404/quizz/109/en.yml @@ -0,0 +1,9 @@ +question: "Why is the API preferred over the CLI for production environments when minting Taproot Assets?" +answer: The API enables assets to be created programmatically, integrating minting into automated systems +wrong_answers: + - The API uses a different security model that is more secure than the CLI's authentication scheme overall + - The API can mint assets immediately without waiting for any on-chain confirmation or fees + - The API supports minting multiple distinct asset types simultaneously in a single request call +explanation: >- + While the CLI is ideal for manual exploration and one-off operations, the REST API enables programmatic asset creation, making it suitable for production applications and automated systems. The security model remains identical between CLI and API, both requiring TLS and macaroon authentication. On-chain confirmation is still required regardless of the interface used. +reviewed: false diff --git a/courses/csv404/quizz/109/question.yml b/courses/csv404/quizz/109/question.yml new file mode 100644 index 00000000000..ce569f084fb --- /dev/null +++ b/courses/csv404/quizz/109/question.yml @@ -0,0 +1,7 @@ +id: "13a9a318-8c77-4fc1-813a-fe3ef6c740b9" +chapterId: "a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87" +difficulty: hard +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/110/en.yml b/courses/csv404/quizz/110/en.yml new file mode 100644 index 00000000000..009348cec44 --- /dev/null +++ b/courses/csv404/quizz/110/en.yml @@ -0,0 +1,9 @@ +question: "What must both the sender and receiver be part of before a Taproot Asset transfer can take place?" +answer: "Membership in a common universe federation" +wrong_answers: + - "The same Lightning Network payment channel" + - "A shared Bitcoin multisig wallet" + - "A mutual peer-to-peer connection over Tor" +explanation: >- + Before any Taproot Asset transfer can take place, both nodes must be part of a common universe federation. The receiver's node needs to know the asset exists, understand its genesis data, and be able to validate incoming proofs. Without proper federation, the transfer will fail. +reviewed: false diff --git a/courses/csv404/quizz/110/question.yml b/courses/csv404/quizz/110/question.yml new file mode 100644 index 00000000000..faabdb28152 --- /dev/null +++ b/courses/csv404/quizz/110/question.yml @@ -0,0 +1,7 @@ +id: "da45b42f-e9a4-4c03-bff4-ee1c66745a44" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/111/en.yml b/courses/csv404/quizz/111/en.yml new file mode 100644 index 00000000000..399c3645cfd --- /dev/null +++ b/courses/csv404/quizz/111/en.yml @@ -0,0 +1,9 @@ +question: "What information does a TAP address encode?" +answer: "The asset ID, requested amount, destination key, and sender's crypto data" +wrong_answers: + - "Only the receiver's public key together with a checksum used for error detection" + - "The asset name, the sender's Lightning node ID, and a payment routing hint" + - "The Bitcoin address, the asset type, and a fee estimation parameter value" +explanation: >- + A TAP address is a long encoded string that contains the asset ID, the requested amount, the receiver's destination key, and cryptographic data needed for the sender to construct a valid transfer. Unlike standard Bitcoin addresses, TAP addresses are unique to each specific asset and amount combination. +reviewed: false diff --git a/courses/csv404/quizz/111/question.yml b/courses/csv404/quizz/111/question.yml new file mode 100644 index 00000000000..4a2ec743ca9 --- /dev/null +++ b/courses/csv404/quizz/111/question.yml @@ -0,0 +1,7 @@ +id: "973f19ed-224f-4ba4-97c1-2930b5dbe59f" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: easy +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/112/en.yml b/courses/csv404/quizz/112/en.yml new file mode 100644 index 00000000000..9a38b501790 --- /dev/null +++ b/courses/csv404/quizz/112/en.yml @@ -0,0 +1,9 @@ +question: "Which CLI command does the receiver use to generate a new TAP address for receiving assets?" +answer: "tapcli addrs new --asset_id --amt " +wrong_answers: + - "tapcli assets receive --asset_id --amt " + - "tapcli addrs generate --type TAP --amount " + - "tapcli wallet newaddr --asset --value " +explanation: >- + The receiver uses the tapcli addrs new command with the --asset_id and --amt flags to generate a new TAP address. This address is specific to the particular asset and amount being requested. The addrs subcommand handles address management, while the new action creates a fresh receiving address. +reviewed: false diff --git a/courses/csv404/quizz/112/question.yml b/courses/csv404/quizz/112/question.yml new file mode 100644 index 00000000000..b8422d251af --- /dev/null +++ b/courses/csv404/quizz/112/question.yml @@ -0,0 +1,7 @@ +id: "53c09e9d-05b5-4cde-b6b0-f5b8ef2f16b2" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: easy +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/113/en.yml b/courses/csv404/quizz/113/en.yml new file mode 100644 index 00000000000..13f37cf1966 --- /dev/null +++ b/courses/csv404/quizz/113/en.yml @@ -0,0 +1,9 @@ +question: "How does a Taproot Asset transfer differ from a standard Bitcoin payment in terms of ownership recording?" +answer: "The on-chain transaction commits to an updated Merkle root, while the detailed asset data is managed off-chain via proof files" +wrong_answers: + - "The on-chain transaction records the full asset metadata directly in the OP_RETURN field of the transaction output" + - "Both the sender and receiver must co-sign a multisig transaction that records ownership directly on-chain publicly" + - "A sidechain records the asset transfer while the main chain only stores a hash of the sidechain block header data" +explanation: >- + Unlike standard Bitcoin payments where the blockchain records ownership changes directly, Taproot Asset transfers commit to an updated Merkle root on-chain that reflects the new ownership structure. The detailed asset data, including the chain of custody, is managed off-chain through cryptographic proof files exchanged between sender and receiver. +reviewed: false diff --git a/courses/csv404/quizz/113/question.yml b/courses/csv404/quizz/113/question.yml new file mode 100644 index 00000000000..0a361a8ce79 --- /dev/null +++ b/courses/csv404/quizz/113/question.yml @@ -0,0 +1,7 @@ +id: "cb8704f4-a1e0-4095-b36a-8cd5ae644c66" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: hard +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/114/en.yml b/courses/csv404/quizz/114/en.yml new file mode 100644 index 00000000000..7b3ecb2c878 --- /dev/null +++ b/courses/csv404/quizz/114/en.yml @@ -0,0 +1,9 @@ +question: "What happens behind the scenes when the sender executes the tapcli assets send command?" +answer: "The node builds an on-chain Bitcoin transaction committing to the updated Merkle tree, generates proofs, and sends them to the receiver" +wrong_answers: + - "The node opens a dedicated Lightning channel with the receiver, streams the full asset data, and closes the channel after final confirmation" + - "The node broadcasts the complete asset metadata directly to the Bitcoin mempool and waits for miners to include it in a confirmed block" + - "The node creates an off-chain state update signed jointly by both parties and periodically settles the aggregate balance fully on-chain" +explanation: >- + When Alice executes tapcli assets send, her node constructs an on-chain Bitcoin transaction that commits to the updated Merkle tree reflecting the new ownership. It also generates cryptographic proof files and transmits them directly to Bob's node. The command returns an on-chain transaction ID that can be verified through any Bitcoin block explorer. +reviewed: false diff --git a/courses/csv404/quizz/114/question.yml b/courses/csv404/quizz/114/question.yml new file mode 100644 index 00000000000..4376bc1e5e0 --- /dev/null +++ b/courses/csv404/quizz/114/question.yml @@ -0,0 +1,7 @@ +id: "8177f250-a517-4704-bc66-9b708d6d1b23" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: hard +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/115/en.yml b/courses/csv404/quizz/115/en.yml new file mode 100644 index 00000000000..3e1a368e4f1 --- /dev/null +++ b/courses/csv404/quizz/115/en.yml @@ -0,0 +1,9 @@ +question: "What is the most common cause of failed Taproot Asset transfers?" +answer: "Incomplete universe federation between the sender and receiver nodes" +wrong_answers: + - "Insufficient Bitcoin balance to cover the on-chain transaction fee" + - "A mismatch between the asset name specified by the sender and receiver" + - "The receiver's node running an incompatible version of the TAPD software" +explanation: >- + According to the chapter, the most common cause of transfer failures is incomplete universe synchronization. If the receiver's node lacks the asset metadata or is not part of the same universe federation as the sender, it cannot validate the incoming proofs and the transfer will fail. Ensuring proper federation setup before attempting transfers is critical. +reviewed: false diff --git a/courses/csv404/quizz/115/question.yml b/courses/csv404/quizz/115/question.yml new file mode 100644 index 00000000000..1a786200373 --- /dev/null +++ b/courses/csv404/quizz/115/question.yml @@ -0,0 +1,7 @@ +id: "58a7c201-51aa-4eaf-888a-96e0dd711ae8" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/116/en.yml b/courses/csv404/quizz/116/en.yml new file mode 100644 index 00000000000..5e0f99319ca --- /dev/null +++ b/courses/csv404/quizz/116/en.yml @@ -0,0 +1,9 @@ +question: "What role do proof files play in Taproot Asset transfers?" +answer: "They form the verifiable chain of custody tracing ownership back to the genesis output" +wrong_answers: + - "They encrypt the asset data so only the receiver can decrypt and claim the tokens" + - "They record the transfer in a proof-of-stake sidechain for faster confirmation" + - "They serve as backup copies of the transaction in case of blockchain reorganization" +explanation: >- + Proof files are cryptographic documents that establish a verifiable chain of custody from the current owner all the way back to the asset's genesis output. They are exchanged off-chain between sender and receiver during a transfer. Without valid proofs, a receiver cannot verify that the sender legitimately owns the assets being transferred. +reviewed: false diff --git a/courses/csv404/quizz/116/question.yml b/courses/csv404/quizz/116/question.yml new file mode 100644 index 00000000000..faff6a45df2 --- /dev/null +++ b/courses/csv404/quizz/116/question.yml @@ -0,0 +1,7 @@ +id: "1b1f183e-aa70-4c68-ab50-0831946f591a" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/117/en.yml b/courses/csv404/quizz/117/en.yml new file mode 100644 index 00000000000..3aa0fda889e --- /dev/null +++ b/courses/csv404/quizz/117/en.yml @@ -0,0 +1,9 @@ +question: "Why are TAP addresses unique to each specific asset and amount combination, unlike standard Bitcoin addresses?" +answer: "Because they encode asset-specific data including the asset ID and requested amount alongside the destination key" +wrong_answers: + - "Because they use a different elliptic curve than Bitcoin addresses, requiring asset parameters in the derivation" + - "Because the Taproot Assets protocol requires a brand-new keypair to be generated for each distinct asset type" + - "Because they include a time-lock parameter that binds the address to one specific transaction confirmation window" +explanation: >- + TAP addresses encode the asset ID, the requested amount, the receiver's destination key, and additional cryptographic data needed by the sender to construct a valid transfer. This makes each address specific to a particular asset and amount, unlike standard Bitcoin addresses which can receive any amount of bitcoin regardless of how they were generated. +reviewed: false diff --git a/courses/csv404/quizz/117/question.yml b/courses/csv404/quizz/117/question.yml new file mode 100644 index 00000000000..de865ffeebf --- /dev/null +++ b/courses/csv404/quizz/117/question.yml @@ -0,0 +1,7 @@ +id: "426324c6-c285-42f3-be50-2b560266fa9b" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: hard +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/118/en.yml b/courses/csv404/quizz/118/en.yml new file mode 100644 index 00000000000..f41ee2f2a20 --- /dev/null +++ b/courses/csv404/quizz/118/en.yml @@ -0,0 +1,9 @@ +question: "In the Alice-to-Bob transfer example, if Alice starts with 100 tokens and sends 10 to Bob, what balances do both nodes show after on-chain confirmation?" +answer: Alice shows 90 tokens and Bob shows 10 tokens, updated automatically once confirmed on-chain +wrong_answers: + - Alice shows 100 tokens and Bob shows 10 tokens, because Alice's original UTXO stays fully unchanged + - Alice shows 89 tokens and Bob shows 10 tokens, with 1 token consumed as a protocol routing fee + - Alice shows 90 tokens and Bob shows 0 tokens until he manually claims them from the mempool +explanation: >- + After the Bitcoin transaction is confirmed on-chain, both nodes update their balances automatically. Alice's balance decreases from 100 to 90, and Bob's balance shows 10. There is no protocol-level fee deducted from the asset amount, and Bob does not need to manually claim the tokens. Balance reconciliation happens automatically upon on-chain confirmation. +reviewed: false diff --git a/courses/csv404/quizz/118/question.yml b/courses/csv404/quizz/118/question.yml new file mode 100644 index 00000000000..2c9a5f735ba --- /dev/null +++ b/courses/csv404/quizz/118/question.yml @@ -0,0 +1,7 @@ +id: "a7f75cb7-a34c-44fd-86d8-7470d5603da4" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: hard +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/119/en.yml b/courses/csv404/quizz/119/en.yml new file mode 100644 index 00000000000..05eebe8c5ad --- /dev/null +++ b/courses/csv404/quizz/119/en.yml @@ -0,0 +1,9 @@ +question: "Which CLI command provides a detailed record of every asset transfer, including transaction IDs, amounts, and confirmation status?" +answer: "tapcli assets transfers" +wrong_answers: + - "tapcli assets history" + - "tapcli transfers list" + - "tapcli wallet transfers" +explanation: >- + The tapcli assets transfers command provides a detailed record of every transfer performed by the node, including transaction IDs, amounts, timestamps, and confirmation status. This is the standard way to review transfer history through the TAPD command line interface. +reviewed: false diff --git a/courses/csv404/quizz/119/question.yml b/courses/csv404/quizz/119/question.yml new file mode 100644 index 00000000000..9d2a03cf8d3 --- /dev/null +++ b/courses/csv404/quizz/119/question.yml @@ -0,0 +1,7 @@ +id: "ddc92fa2-bffb-48a2-a381-a5603ac4efce" +chapterId: "d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98" +difficulty: easy +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/120/en.yml b/courses/csv404/quizz/120/en.yml new file mode 100644 index 00000000000..4a7180b27ed --- /dev/null +++ b/courses/csv404/quizz/120/en.yml @@ -0,0 +1,9 @@ +question: "How many endpoints are involved in the API workflow for sending Taproot Assets?" +answer: "Three endpoints: verify assets, generate address, and send funds" +wrong_answers: + - "One single endpoint that handles verification, addressing, and sending together" + - "Two endpoints: one for address generation and one for sending the assets" + - "Five endpoints for verification, address creation, signing, sending, confirmation" +explanation: >- + The API workflow for sending Taproot Assets uses three endpoints: a GET endpoint to verify available assets, a POST endpoint to generate a receiving address, and a POST endpoint to execute the transfer. This three-step process mirrors the CLI workflow but through HTTP requests. +reviewed: false diff --git a/courses/csv404/quizz/120/question.yml b/courses/csv404/quizz/120/question.yml new file mode 100644 index 00000000000..3aa8e271e95 --- /dev/null +++ b/courses/csv404/quizz/120/question.yml @@ -0,0 +1,7 @@ +id: "c824ee86-6cf4-4235-9e26-7675693c9069" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/121/en.yml b/courses/csv404/quizz/121/en.yml new file mode 100644 index 00000000000..eb3b6008e7c --- /dev/null +++ b/courses/csv404/quizz/121/en.yml @@ -0,0 +1,9 @@ +question: "What API endpoint is used to generate a new receiving address for Taproot Assets?" +answer: "POST /v1/taproot-assets/addrs" +wrong_answers: + - "POST /v1/taproot-assets/addrs/new" + - "GET /v1/taproot-assets/addrs/create" + - "POST /v1/taproot-assets/wallet/addrs" +explanation: >- + The receiving address is generated by sending a POST request to /v1/taproot-assets/addrs with a JSON payload containing the asset_id and amt fields. The response includes an encoded field containing the TAP address string that can be used for the transfer. The endpoint follows RESTful conventions where POST creates a new resource. +reviewed: false diff --git a/courses/csv404/quizz/121/question.yml b/courses/csv404/quizz/121/question.yml new file mode 100644 index 00000000000..8d06e972609 --- /dev/null +++ b/courses/csv404/quizz/121/question.yml @@ -0,0 +1,7 @@ +id: "9bc333fd-eafa-4523-8d6a-26255cef6c04" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: easy +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/122/en.yml b/courses/csv404/quizz/122/en.yml new file mode 100644 index 00000000000..48456324acc --- /dev/null +++ b/courses/csv404/quizz/122/en.yml @@ -0,0 +1,9 @@ +question: "How is the TAP address extracted from the address generation API response?" +answer: "From the 'encoded' field in the JSON response returned by the API" +wrong_answers: + - "From the 'address' field in the HTTP response headers, not the body" + - "From the 'tap_address' field within the JSON response body itself" + - "From the 'result.destination' nested field in the JSON response" +explanation: >- + After posting to the /v1/taproot-assets/addrs endpoint, the TAP address is retrieved from the encoded field of the JSON response using addr_response.json()["encoded"]. This encoded string contains all the information the sender needs to construct a valid transfer, including asset ID, amount, and destination key. +reviewed: false diff --git a/courses/csv404/quizz/122/question.yml b/courses/csv404/quizz/122/question.yml new file mode 100644 index 00000000000..84c1a45855b --- /dev/null +++ b/courses/csv404/quizz/122/question.yml @@ -0,0 +1,7 @@ +id: "f80d3807-4203-4c2e-8c41-2ce13eba5a20" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: easy +duration: 20 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/123/en.yml b/courses/csv404/quizz/123/en.yml new file mode 100644 index 00000000000..94c18b9cb00 --- /dev/null +++ b/courses/csv404/quizz/123/en.yml @@ -0,0 +1,9 @@ +question: "What is the structure of the JSON payload sent to the send endpoint to execute a Taproot Asset transfer?" +answer: "A JSON object with a 'tap_addrs' key containing an array of TAP address strings" +wrong_answers: + - "A JSON object with 'destination' and 'amount' keys specifying the receiver and quantity" + - "A JSON object with 'asset_id', 'recipient_key', and 'amt' keys describing the transfer" + - "A JSON object with a 'transfers' key containing an array of transfer detail objects" +explanation: >- + The send endpoint expects a JSON payload with a tap_addrs key containing an array of TAP address strings. The TAP address itself already encodes the asset ID, amount, and destination information, so no additional parameters are needed. This design keeps the send request simple since all transfer details are embedded in the address. +reviewed: false diff --git a/courses/csv404/quizz/123/question.yml b/courses/csv404/quizz/123/question.yml new file mode 100644 index 00000000000..28445fb1319 --- /dev/null +++ b/courses/csv404/quizz/123/question.yml @@ -0,0 +1,7 @@ +id: "10bd64a7-b49c-4758-9eac-6a0da1da2e1a" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/124/en.yml b/courses/csv404/quizz/124/en.yml new file mode 100644 index 00000000000..8689c598766 --- /dev/null +++ b/courses/csv404/quizz/124/en.yml @@ -0,0 +1,9 @@ +question: "What is the API endpoint used to execute a Taproot Asset transfer?" +answer: "POST /v1/taproot-assets/send" +wrong_answers: + - "POST /v1/taproot-assets/transfer" + - "POST /v1/taproot-assets/tx/send" + - "PUT /v1/taproot-assets/send" +explanation: >- + The transfer is executed by sending a POST request to /v1/taproot-assets/send with the TAP address in the payload. This endpoint processes the transfer by constructing the on-chain transaction, generating proofs, and transmitting them to the receiver's node. The endpoint uses POST because it creates a new transaction resource. +reviewed: false diff --git a/courses/csv404/quizz/124/question.yml b/courses/csv404/quizz/124/question.yml new file mode 100644 index 00000000000..c1d10a0e705 --- /dev/null +++ b/courses/csv404/quizz/124/question.yml @@ -0,0 +1,7 @@ +id: "4493bbc8-6a11-445e-8a5b-e5c03e5fcd09" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: easy +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/125/en.yml b/courses/csv404/quizz/125/en.yml new file mode 100644 index 00000000000..d5c43d9a043 --- /dev/null +++ b/courses/csv404/quizz/125/en.yml @@ -0,0 +1,9 @@ +question: "After submitting a transfer via the API, who is responsible for monitoring whether the transaction has been confirmed on-chain?" +answer: "The application itself must monitor the state, as the API does not provide push notifications for confirmations" +wrong_answers: + - "TAPD automatically sends a signed webhook callback to a pre-configured URL once the transaction confirms on-chain" + - "The receiver's node sends an acknowledgment message through the universe federation once the transfer is confirmed" + - "The API provides a WebSocket subscription that emits an event whenever the transfer status changes to a new state" +explanation: >- + The TAPD API does not provide push notifications when a transfer confirms. Your application is responsible for polling or otherwise monitoring the on-chain state to determine when the Bitcoin transaction has been confirmed in a block. This means production applications need to implement their own confirmation monitoring logic. +reviewed: false diff --git a/courses/csv404/quizz/125/question.yml b/courses/csv404/quizz/125/question.yml new file mode 100644 index 00000000000..43f9aae711b --- /dev/null +++ b/courses/csv404/quizz/125/question.yml @@ -0,0 +1,7 @@ +id: "4a92950b-1e24-4970-8fb0-c144a9af4442" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: intermediate +duration: 30 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/126/en.yml b/courses/csv404/quizz/126/en.yml new file mode 100644 index 00000000000..dff3bcc1a0f --- /dev/null +++ b/courses/csv404/quizz/126/en.yml @@ -0,0 +1,9 @@ +question: "Which of the following error scenarios must be handled when building transfer functionality into production applications?" +answer: "Insufficient balance, invalid or expired TAP addresses, and missing universe data on the receiver" +wrong_answers: + - "Network congestion, double-spend attempts, and unexpectedly expired TLS certificates on the server" + - "Rate limiting on API calls, insufficient gas fees, and smart contract reverts during execution" + - "Channel capacity limits, Lightning routing failures, and invoice expiration timing mismatches" +explanation: >- + The chapter specifies three error scenarios for production applications: insufficient balance (the send endpoint rejects requests if the node lacks enough of the specified asset), invalid address (malformed or expired TAP addresses produce an error), and missing universe data (if the receiver's node lacks asset metadata, address generation fails). These are Taproot-Asset-specific concerns distinct from Lightning or EVM-based error handling. +reviewed: false diff --git a/courses/csv404/quizz/126/question.yml b/courses/csv404/quizz/126/question.yml new file mode 100644 index 00000000000..22a99678615 --- /dev/null +++ b/courses/csv404/quizz/126/question.yml @@ -0,0 +1,7 @@ +id: "2ca3b0b1-fd7b-463b-ac2d-2dd19c95c50e" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: intermediate +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/127/en.yml b/courses/csv404/quizz/127/en.yml new file mode 100644 index 00000000000..7c5e31154dd --- /dev/null +++ b/courses/csv404/quizz/127/en.yml @@ -0,0 +1,9 @@ +question: "What happens when the API send endpoint receives a request but the node does not hold enough of the specified asset?" +answer: "The send endpoint rejects the request with an error response indicating insufficient balance" +wrong_answers: + - "The endpoint queues the transfer and retries automatically once additional assets are received" + - "The endpoint completes the transfer for the available amount and returns a partial transfer receipt" + - "The endpoint creates the transaction but marks it as pending until the balance is replenished" +explanation: >- + When a node does not hold enough of the specified asset, the send endpoint rejects the request outright. It does not perform a partial transfer, queue the request, or create a pending transaction. Production applications must check the available balance via the GET /v1/taproot-assets/assets endpoint before attempting a send to handle this scenario gracefully. +reviewed: false diff --git a/courses/csv404/quizz/127/question.yml b/courses/csv404/quizz/127/question.yml new file mode 100644 index 00000000000..bf493a72d3f --- /dev/null +++ b/courses/csv404/quizz/127/question.yml @@ -0,0 +1,7 @@ +id: "5ba453ef-a80e-4df8-a6c6-9ebe3ac2cb9f" +chapterId: "b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19" +difficulty: hard +duration: 35 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/130/en.yml b/courses/csv404/quizz/130/en.yml new file mode 100644 index 00000000000..4df3831fbc9 --- /dev/null +++ b/courses/csv404/quizz/130/en.yml @@ -0,0 +1,9 @@ +question: "What is the purpose of burning assets in the Taproot Assets lifecycle?" +answer: "To permanently destroy assets and remove them from circulation forever" +wrong_answers: + - "To temporarily lock assets in a time-locked smart contract for later retrieval" + - "To transfer assets to the protocol treasury for redistribution to validators" + - "To convert Taproot Assets into native on-chain Bitcoin satoshis directly" +explanation: >- + Burning is the permanent destruction of assets, removing them from circulation forever. It is the third core operation in the Taproot Assets lifecycle alongside minting and sending. Once burned and confirmed on-chain, assets cannot be recovered by any means, making it fundamentally different from locking or transferring. +reviewed: false diff --git a/courses/csv404/quizz/130/question.yml b/courses/csv404/quizz/130/question.yml new file mode 100644 index 00000000000..7a2a7dbf3d1 --- /dev/null +++ b/courses/csv404/quizz/130/question.yml @@ -0,0 +1,7 @@ +id: "790b1bf1-d6c7-42e6-a0dc-cf7112cdfa35" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/131/en.yml b/courses/csv404/quizz/131/en.yml new file mode 100644 index 00000000000..f4ce858d84a --- /dev/null +++ b/courses/csv404/quizz/131/en.yml @@ -0,0 +1,9 @@ +question: "What two parameters does the tapcli burn command require?" +answer: "The asset ID to identify the asset, and the amount of units to destroy" +wrong_answers: + - "The asset ID and the destination burn address for the transaction" + - "The amount to burn and the current transaction fee rate in satoshis per byte" + - "The asset name and the exact percentage of total supply to destroy" +explanation: >- + The burn command syntax is `tapcli assets burn --asset_id --amount 10`, requiring exactly two parameters: the asset ID identifying which asset to burn and the amount specifying how many units to destroy. There is no destination address because burned assets are destroyed, and the fee rate is handled separately from the burn parameters. +reviewed: false diff --git a/courses/csv404/quizz/131/question.yml b/courses/csv404/quizz/131/question.yml new file mode 100644 index 00000000000..a23a7a09ed5 --- /dev/null +++ b/courses/csv404/quizz/131/question.yml @@ -0,0 +1,7 @@ +id: "b21b82c9-7809-48bc-8178-5fba4bd35af9" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/132/en.yml b/courses/csv404/quizz/132/en.yml new file mode 100644 index 00000000000..59eb00ff22d --- /dev/null +++ b/courses/csv404/quizz/132/en.yml @@ -0,0 +1,9 @@ +question: "What safety mechanism does TAPD present before executing a burn from the CLI?" +answer: An interactive confirmation prompt warning about the permanent nature of the operation +wrong_answers: + - A mandatory 24-hour cooling-off period before the burn transaction is broadcast on-chain + - An automatic backup of the asset proof file to a secondary encrypted storage location + - A multi-signature approval requiring at least two authorized keys to proceed with burning +explanation: >- + TAPD presents an interactive confirmation prompt that explicitly warns the user about the permanent and irreversible nature of the burn operation. The user must actively confirm before the burn proceeds. This is a critical safety feature because once burned and confirmed on-chain, assets cannot be recovered. +reviewed: false diff --git a/courses/csv404/quizz/132/question.yml b/courses/csv404/quizz/132/question.yml new file mode 100644 index 00000000000..906e9639a2c --- /dev/null +++ b/courses/csv404/quizz/132/question.yml @@ -0,0 +1,7 @@ +id: "884b09ec-406d-4575-9199-916bd621cd51" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/133/en.yml b/courses/csv404/quizz/133/en.yml new file mode 100644 index 00000000000..b0df5f15308 --- /dev/null +++ b/courses/csv404/quizz/133/en.yml @@ -0,0 +1,9 @@ +question: "Why is it recommended to verify your asset inventory with `tapcli assets list` before executing a burn?" +answer: "To identify the exact asset and confirm its asset ID, since burning the wrong asset is irreversible" +wrong_answers: + - "To ensure the TAPD daemon is fully synchronized with the entire Lightning Network before proceeding" + - "To check that the asset has received sufficient confirmations from the original minting transaction" + - "To verify that the asset supports the burn opcode, since some asset types are marked non-burnable" +explanation: >- + Before any destructive operation, you must verify your current holdings to carefully identify the exact asset you intend to burn and note its asset ID. A mistake at this stage could result in burning the wrong asset, and since burns are irreversible once confirmed on-chain, there is no way to undo the error. This pre-burn check is a critical safety step. +reviewed: false diff --git a/courses/csv404/quizz/133/question.yml b/courses/csv404/quizz/133/question.yml new file mode 100644 index 00000000000..074b5b49b04 --- /dev/null +++ b/courses/csv404/quizz/133/question.yml @@ -0,0 +1,7 @@ +id: "fd52ea62-b50c-44ff-9ed5-871146a862b8" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/134/en.yml b/courses/csv404/quizz/134/en.yml new file mode 100644 index 00000000000..7595c6d6974 --- /dev/null +++ b/courses/csv404/quizz/134/en.yml @@ -0,0 +1,9 @@ +question: "How is the burn operation functionally described in terms of traditional Bitcoin transactions?" +answer: "It is equivalent to sending funds to an address with no known private key" +wrong_answers: + - "It is equivalent to creating a coinbase transaction that returns value to miners" + - "It is equivalent to a double-spend that invalidates the original asset outputs" + - "It is equivalent to a timelocked transaction that becomes unspendable after expiry" +explanation: >- + The chapter describes that you should treat every burn command as if it were a transaction sending funds to an address with no known private key, because functionally, that is exactly what it is. The assets are sent to an unspendable destination, making them permanently irrecoverable. This analogy helps clarify why burns are truly irreversible. +reviewed: false diff --git a/courses/csv404/quizz/134/question.yml b/courses/csv404/quizz/134/question.yml new file mode 100644 index 00000000000..ebb1f7048d2 --- /dev/null +++ b/courses/csv404/quizz/134/question.yml @@ -0,0 +1,7 @@ +id: "33c31923-00ae-4fda-a228-2aa965a94baf" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/135/en.yml b/courses/csv404/quizz/135/en.yml new file mode 100644 index 00000000000..9c1161d52b5 --- /dev/null +++ b/courses/csv404/quizz/135/en.yml @@ -0,0 +1,9 @@ +question: "In automated environments, how can the CLI burn confirmation prompt be handled?" +answer: "It can be bypassed with a flag, though this should be treated with extreme caution" +wrong_answers: + - "It cannot be bypassed and always requires manual input regardless of environment" + - "It is replaced by a mandatory email notification to the node administrator for approval" + - "It is automatically skipped when TAPD detects it is running inside a container runtime" +explanation: >- + For automated environments, the interactive confirmation prompt can be bypassed with a flag. However, the chapter emphasizes that this should be treated with extreme caution, because removing the safety prompt increases the risk of accidentally burning assets in a pipeline or script where human review is absent. +reviewed: false diff --git a/courses/csv404/quizz/135/question.yml b/courses/csv404/quizz/135/question.yml new file mode 100644 index 00000000000..eaea86130ba --- /dev/null +++ b/courses/csv404/quizz/135/question.yml @@ -0,0 +1,7 @@ +id: "7f3ae19c-8b93-45ee-a17b-c2d669b0855b" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/136/en.yml b/courses/csv404/quizz/136/en.yml new file mode 100644 index 00000000000..6615a4d3268 --- /dev/null +++ b/courses/csv404/quizz/136/en.yml @@ -0,0 +1,9 @@ +question: "A stablecoin issuer holds 90 units of a Taproot Asset and burns 10. What is the expected balance after on-chain confirmation, and why might the result differ from simply subtracting the burned amount from the initial mint?" +answer: "The balance is 80, since the asset was already partly spent before the burn, so actual balance must be verified" +wrong_answers: + - "The balance is 90 because the burn only takes effect after two additional confirmations beyond the mint" + - "The balance is 80 because the burned amount is held in escrow until the next block confirms it finally" + - "The balance is 10 because the burn operation inverts the remaining supply, destroying the larger portion" +explanation: >- + The chapter shows that after burning 10 units, the balance reflects 80, noting this is 90 minus 10. The key insight is that the pre-burn balance was 90, not necessarily the original minted amount, because prior sends may have already reduced the balance. This is why verifying your actual current holdings before and after a burn is essential rather than relying on assumptions about total supply. +reviewed: false diff --git a/courses/csv404/quizz/136/question.yml b/courses/csv404/quizz/136/question.yml new file mode 100644 index 00000000000..3c5043b08c8 --- /dev/null +++ b/courses/csv404/quizz/136/question.yml @@ -0,0 +1,7 @@ +id: "6724f390-ee5b-4d5b-96f4-f85a138c22c2" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/137/en.yml b/courses/csv404/quizz/137/en.yml new file mode 100644 index 00000000000..36a9a15efea --- /dev/null +++ b/courses/csv404/quizz/137/en.yml @@ -0,0 +1,9 @@ +question: "What are the three fundamental lifecycle operations in the Taproot Assets protocol, and what role does burning play as the final operation?" +answer: "Minting creates assets, sending transfers them between parties, and burning permanently destroys them to remove supply from circulation" +wrong_answers: + - "Minting creates assets, staking locks them permanently for passive yield generation, and burning recycles them into entirely new asset types" + - "Issuance registers assets on-chain, routing delivers them through payment channels, and burning archives them in cold storage" + - "Anchoring commits assets to Bitcoin, swapping exchanges them for Lightning payments, and burning converts them to on-chain satoshis" +explanation: >- + The three core lifecycle operations are minting (creation), sending (transfer between parties), and burning (permanent destruction). Burning completes the lifecycle by providing a mechanism to permanently remove assets from circulation. This is essential for use cases like stablecoin redemption, test token cleanup, or governance-driven supply reduction. +reviewed: false diff --git a/courses/csv404/quizz/137/question.yml b/courses/csv404/quizz/137/question.yml new file mode 100644 index 00000000000..dde15c996c9 --- /dev/null +++ b/courses/csv404/quizz/137/question.yml @@ -0,0 +1,7 @@ +id: "c3a3f7eb-3205-4d0c-94a1-a2e96479a857" +chapterId: "e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/140/en.yml b/courses/csv404/quizz/140/en.yml new file mode 100644 index 00000000000..a6f9c6223a5 --- /dev/null +++ b/courses/csv404/quizz/140/en.yml @@ -0,0 +1,9 @@ +question: "What HTTP method is used to execute a burn operation through the Taproot Assets REST API?" +answer: "A POST request sent to the burn endpoint" +wrong_answers: + - "A DELETE request sent to the assets endpoint" + - "A PUT request sent to the destroy endpoint" + - "A GET request to the burn endpoint with parameters" +explanation: >- + The burn operation uses a POST request to the `/v1/taproot-assets/burn` endpoint, as shown in the chapter's code example with `requests.post()`. This follows REST conventions where POST is used for actions that create or trigger operations, rather than DELETE which might seem intuitive but is not how the API is designed. +reviewed: false diff --git a/courses/csv404/quizz/140/question.yml b/courses/csv404/quizz/140/question.yml new file mode 100644 index 00000000000..074127ac05d --- /dev/null +++ b/courses/csv404/quizz/140/question.yml @@ -0,0 +1,7 @@ +id: "62fbc7ed-40e0-4d25-81ef-8976487b9a2b" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/141/en.yml b/courses/csv404/quizz/141/en.yml new file mode 100644 index 00000000000..ec6f4cf3365 --- /dev/null +++ b/courses/csv404/quizz/141/en.yml @@ -0,0 +1,9 @@ +question: "What is the exact confirmation string required in the API burn payload to authorize asset destruction?" +answer: "\"assets will be destroyed\"" +wrong_answers: + - "\"confirm burn operation\"" + - "\"yes, destroy permanently\"" + - "\"permanently delete assets\"" +explanation: >- + The API requires the exact string "assets will be destroyed" as the value of the `confirmation_str` field in the burn payload. This specific string serves as the programmatic equivalent of the CLI's interactive confirmation prompt. Without this exact string, the API rejects the burn request entirely, forcing developers to explicitly acknowledge the destructive nature of the operation. +reviewed: false diff --git a/courses/csv404/quizz/141/question.yml b/courses/csv404/quizz/141/question.yml new file mode 100644 index 00000000000..08640e693b1 --- /dev/null +++ b/courses/csv404/quizz/141/question.yml @@ -0,0 +1,7 @@ +id: "c8335da7-5099-4f82-804c-889fbafa5876" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/142/en.yml b/courses/csv404/quizz/142/en.yml new file mode 100644 index 00000000000..90fd992eebe --- /dev/null +++ b/courses/csv404/quizz/142/en.yml @@ -0,0 +1,9 @@ +question: "What happens if the confirmation string is omitted from the API burn request payload?" +answer: "The API rejects the burn request entirely and the operation does not proceed" +wrong_answers: + - "The API queues the burn request and waits for a follow-up confirmation call" + - "The API executes the burn but flags it as unconfirmed in the response metadata" + - "The API returns a warning but still processes the burn after a ten-second delay" +explanation: >- + Without the required confirmation string, the API rejects the burn request entirely. This is a deliberate safety mechanism that forces the developer to explicitly acknowledge that assets will be permanently destroyed. The confirmation string is mandatory, not optional, and the burn simply will not execute without it. +reviewed: false diff --git a/courses/csv404/quizz/142/question.yml b/courses/csv404/quizz/142/question.yml new file mode 100644 index 00000000000..27d37e32a86 --- /dev/null +++ b/courses/csv404/quizz/142/question.yml @@ -0,0 +1,7 @@ +id: "9bc1ae5d-3cb8-46cb-bbf7-e52620d45e4e" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/143/en.yml b/courses/csv404/quizz/143/en.yml new file mode 100644 index 00000000000..273ac74d4ca --- /dev/null +++ b/courses/csv404/quizz/143/en.yml @@ -0,0 +1,9 @@ +question: "What are the three fields required in the burn payload when using the Taproot Assets REST API?" +answer: "asset_id, amount, and confirmation_str" +wrong_answers: + - "asset_id, amount, and fee_rate_override" + - "asset_name, amount, and confirmation_str" + - "asset_id, confirmation_str, and dest_address" +explanation: >- + The burn payload requires three fields: `asset_id` (the hex-encoded identifier of the asset to burn), `amount` (the number of units to destroy), and `confirmation_str` (set to "assets will be destroyed"). The asset_id is a hex string, not a name, and there is no destination address since burned assets are destroyed rather than sent somewhere. +reviewed: false diff --git a/courses/csv404/quizz/143/question.yml b/courses/csv404/quizz/143/question.yml new file mode 100644 index 00000000000..ff812083407 --- /dev/null +++ b/courses/csv404/quizz/143/question.yml @@ -0,0 +1,7 @@ +id: "b0eacb0a-69de-40de-b649-9b4e7be5ffe6" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/144/en.yml b/courses/csv404/quizz/144/en.yml new file mode 100644 index 00000000000..63f833d3715 --- /dev/null +++ b/courses/csv404/quizz/144/en.yml @@ -0,0 +1,9 @@ +question: "What is the recommended practice for production systems after executing a burn through the API?" +answer: "Log every burn response in its entirety as a permanent audit record" +wrong_answers: + - "Send an automated notification to all asset holders about the supply change" + - "Immediately re-mint the same number of assets to maintain a constant supply" + - "Broadcast the burn transaction hash to a public block explorer for verification" +explanation: >- + For production systems, the chapter recommends logging every burn response in its entirety as an audit record. This creates a permanent trail of all destructive operations, which is essential for compliance, debugging, and accountability. Simply broadcasting to an explorer or notifying holders does not provide the same level of internal record-keeping. +reviewed: false diff --git a/courses/csv404/quizz/144/question.yml b/courses/csv404/quizz/144/question.yml new file mode 100644 index 00000000000..8aea91f5436 --- /dev/null +++ b/courses/csv404/quizz/144/question.yml @@ -0,0 +1,7 @@ +id: "028796c5-97b8-488d-b591-7df7e235b5a4" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/145/en.yml b/courses/csv404/quizz/145/en.yml new file mode 100644 index 00000000000..7366cff6938 --- /dev/null +++ b/courses/csv404/quizz/145/en.yml @@ -0,0 +1,9 @@ +question: "What is the API endpoint path used to query current asset holdings before and after a burn operation?" +answer: "/v1/taproot-assets/assets using a GET request" +wrong_answers: + - "/v1/taproot-assets/balance using a GET request" + - "/v1/taproot-assets/inventory using a POST request" + - "/v1/taproot-assets/wallet/assets using a GET request" +explanation: >- + The pre-burn and post-burn inventory checks both use a GET request to `/v1/taproot-assets/assets`. This is the same endpoint used throughout the Taproot Assets API for listing assets. After the burn operation and on-chain confirmation, querying this endpoint again confirms the reduced balance. +reviewed: false diff --git a/courses/csv404/quizz/145/question.yml b/courses/csv404/quizz/145/question.yml new file mode 100644 index 00000000000..ff1eca0c316 --- /dev/null +++ b/courses/csv404/quizz/145/question.yml @@ -0,0 +1,7 @@ +id: "475dc539-8ac3-43a8-b1ad-c8671e0ea2fd" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/146/en.yml b/courses/csv404/quizz/146/en.yml new file mode 100644 index 00000000000..997159ad0a1 --- /dev/null +++ b/courses/csv404/quizz/146/en.yml @@ -0,0 +1,9 @@ +question: "How does the API's confirmation_str parameter relate to the CLI's interactive confirmation prompt in terms of safety design?" +answer: The confirmation_str is the programmatic equivalent of the CLI's interactive prompt, ensuring developers explicitly acknowledge destruction even within automated code paths +wrong_answers: + - The confirmation_str provides stronger security than the CLI prompt because it is cryptographically signed by the node's TLS certificate and root macaroon + - The confirmation_str replaces the CLI prompt entirely, meaning CLI users must also provide the string instead of interactive confirmation + - The confirmation_str is optional for authenticated API sessions, unlike the CLI prompt which is always mandatory regardless of context +explanation: >- + The confirmation string is described as the API equivalent of the CLI's interactive prompt. Both serve the same purpose: forcing the operator to explicitly acknowledge that assets will be permanently destroyed before the operation proceeds. The API version uses a required string parameter because automated code cannot respond to interactive prompts, but the safety intent is identical. +reviewed: false diff --git a/courses/csv404/quizz/146/question.yml b/courses/csv404/quizz/146/question.yml new file mode 100644 index 00000000000..1904f49d3e4 --- /dev/null +++ b/courses/csv404/quizz/146/question.yml @@ -0,0 +1,7 @@ +id: "4a1b7276-5286-440c-86d9-5fee18dc051f" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/147/en.yml b/courses/csv404/quizz/147/en.yml new file mode 100644 index 00000000000..85e10ebd4ca --- /dev/null +++ b/courses/csv404/quizz/147/en.yml @@ -0,0 +1,9 @@ +question: "In the API burn request, the asset_id field expects a hex-encoded value. What TLS-related parameters are also required for the API call to reach the TAPD node?" +answer: "Authentication headers and a TLS certificate path for verification" +wrong_answers: + - "A macaroon cookie and an SSH tunnel endpoint for encrypted transport" + - "An API key query parameter and a self-signed certificate fingerprint hash" + - "An OAuth bearer token and a mutual TLS client certificate for bidirectional auth" +explanation: >- + The code examples show that API calls require both `headers` (for authentication, typically containing macaroon-based credentials) and a `verify=cert_path` parameter pointing to the TLS certificate. These are standard TAPD API security requirements that ensure the connection is both authenticated and encrypted, protecting sensitive operations like burns from unauthorized access. +reviewed: false diff --git a/courses/csv404/quizz/147/question.yml b/courses/csv404/quizz/147/question.yml new file mode 100644 index 00000000000..8ed718c5247 --- /dev/null +++ b/courses/csv404/quizz/147/question.yml @@ -0,0 +1,7 @@ +id: "e83d11e2-7b3c-44b4-9a37-d4e9000ecbcb" +chapterId: "c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/150/en.yml b/courses/csv404/quizz/150/en.yml new file mode 100644 index 00000000000..88c790a7720 --- /dev/null +++ b/courses/csv404/quizz/150/en.yml @@ -0,0 +1,9 @@ +question: "What is the absolute rule when updating TAPD, regardless of the installation method used?" +answer: "Never delete your data directories (.tapd, .lnd, .bitcoin) during an update" +wrong_answers: + - "Always perform the update on a separate test machine before applying to production" + - "Always downgrade to the previous version first before installing the new release" + - "Always disconnect all Lightning channels before beginning the update process" +explanation: >- + The chapter states this rule as absolute: never delete your data directories (.tapd, .lnd, .bitcoin) during an update. These folders contain your wallet, channel state, asset proofs, and blockchain data. The binaries are replaceable, but the data is not. Losing these directories means losing access to your assets and channels permanently. +reviewed: false diff --git a/courses/csv404/quizz/150/question.yml b/courses/csv404/quizz/150/question.yml new file mode 100644 index 00000000000..8de3281e40f --- /dev/null +++ b/courses/csv404/quizz/150/question.yml @@ -0,0 +1,7 @@ +id: "fa249ce2-30b2-4b71-84c0-47d71ef2a190" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/151/en.yml b/courses/csv404/quizz/151/en.yml new file mode 100644 index 00000000000..cd0f2b629de --- /dev/null +++ b/courses/csv404/quizz/151/en.yml @@ -0,0 +1,9 @@ +question: "When updating a Polar installation, what might be required for major version jumps?" +answer: "Polar itself may need to be replaced, and networks may need to be recreated from scratch" +wrong_answers: + - "Each node must be individually migrated using a dedicated command-line export and import tool" + - "The underlying Docker engine must be manually upgraded to match the new Polar version exactly" + - "A database migration script must be run manually against each node's own data directory" +explanation: >- + For major version jumps, Polar itself may need to be replaced by downloading the latest release. The chapter warns that significant updates sometimes require recreating your networks from scratch, which is why noting down your current network topology beforehand is recommended so you can recreate it if needed. +reviewed: false diff --git a/courses/csv404/quizz/151/question.yml b/courses/csv404/quizz/151/question.yml new file mode 100644 index 00000000000..b3ddb283da6 --- /dev/null +++ b/courses/csv404/quizz/151/question.yml @@ -0,0 +1,7 @@ +id: "b9493dce-d676-4dc7-9ba5-75ba1d7d7eca" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/152/en.yml b/courses/csv404/quizz/152/en.yml new file mode 100644 index 00000000000..ef350aa705c --- /dev/null +++ b/courses/csv404/quizz/152/en.yml @@ -0,0 +1,9 @@ +question: "What verification step should be performed after downloading new TAPD binaries for a binary installation update?" +answer: "Verify the SHA256 checksum of the downloaded archive against the official release notes" +wrong_answers: + - "Run the binary with a --self-test flag to validate its internal integrity checks" + - "Compare the file size of the new binary against the previous version's binary exactly" + - "Submit the binary hash to the Lightning Labs verification portal for authentication" +explanation: >- + The chapter instructs users to verify the SHA256 checksum of the downloaded tarball against the values published in the release notes using `sha256sum`. This ensures the downloaded file has not been tampered with or corrupted during transfer, which is a critical security step when updating node software that manages valuable assets. +reviewed: false diff --git a/courses/csv404/quizz/152/question.yml b/courses/csv404/quizz/152/question.yml new file mode 100644 index 00000000000..28ba55834ad --- /dev/null +++ b/courses/csv404/quizz/152/question.yml @@ -0,0 +1,7 @@ +id: "ee4653f0-161b-4734-bea5-dffcf2931863" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/153/en.yml b/courses/csv404/quizz/153/en.yml new file mode 100644 index 00000000000..30bf0d14dc5 --- /dev/null +++ b/courses/csv404/quizz/153/en.yml @@ -0,0 +1,9 @@ +question: "What is the first step when updating a binary installation of TAPD?" +answer: "Stop the running TAPD service using systemctl, before touching any files" +wrong_answers: + - "Back up the binary files to a temporary backup directory for rollback purposes" + - "Download the new release archive before stopping any running services first" + - "Remove the existing data directory to prepare for a clean fresh installation" +explanation: >- + The first step in the binary update procedure is to stop the running TAPD service with `sudo systemctl stop tapd`. This ensures the daemon is not running while its binaries are being replaced, preventing potential corruption or conflicts. Only after stopping the service should you proceed to remove old binaries and install new ones. +reviewed: false diff --git a/courses/csv404/quizz/153/question.yml b/courses/csv404/quizz/153/question.yml new file mode 100644 index 00000000000..9e356ddf61a --- /dev/null +++ b/courses/csv404/quizz/153/question.yml @@ -0,0 +1,7 @@ +id: "484d22e6-c079-48ef-8f61-41f01ab76ced" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/154/en.yml b/courses/csv404/quizz/154/en.yml new file mode 100644 index 00000000000..799f9fd1dfe --- /dev/null +++ b/courses/csv404/quizz/154/en.yml @@ -0,0 +1,9 @@ +question: "How does the source installation update procedure differ from the binary installation procedure in stopping the TAPD daemon?" +answer: "Source install uses `tapcli stop` for graceful shutdown, then `systemctl stop tapd`; binary install only uses systemctl" +wrong_answers: + - "Source installation requires sending a SIGTERM signal directly to the process, while binary installation uses systemctl" + - "Source installation stops TAPD by killing the Go process from the build directory, while binary installation uses systemctl" + - "Both installation procedures are identical, relying solely on `systemctl stop tapd` to halt the service" +explanation: >- + The source installation update procedure first issues `tapcli stop` for a graceful daemon shutdown, then follows with `sudo systemctl stop tapd` to ensure the service is fully stopped. The binary installation procedure only uses `sudo systemctl stop tapd`. The graceful `tapcli stop` allows the daemon to cleanly finalize any pending operations before the service manager takes over. +reviewed: false diff --git a/courses/csv404/quizz/154/question.yml b/courses/csv404/quizz/154/question.yml new file mode 100644 index 00000000000..aeee8eb3174 --- /dev/null +++ b/courses/csv404/quizz/154/question.yml @@ -0,0 +1,7 @@ +id: "88b128f9-8309-4e5f-9a85-313a78be9f1e" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/155/en.yml b/courses/csv404/quizz/155/en.yml new file mode 100644 index 00000000000..4907dcdfaab --- /dev/null +++ b/courses/csv404/quizz/155/en.yml @@ -0,0 +1,9 @@ +question: "When updating TAPD from source, what git commands are used to obtain the desired version?" +answer: "`git fetch --all` followed by `git checkout` of the specific desired version tag" +wrong_answers: + - "`git pull origin main` followed by `git merge` of the release branch" + - "`git clone` of the repo into a new directory, then `git switch` to the tag" + - "`git submodule update --remote` followed by `git rebase` onto the tag" +explanation: >- + The source update procedure uses `git fetch --all` to download all remote references without merging, then `git checkout v0.5.0` (or the desired version tag) to switch to the specific release. This approach ensures you get the exact tagged release rather than potentially unstable code from a branch tip. After checkout, `make install` compiles and installs the new version. +reviewed: false diff --git a/courses/csv404/quizz/155/question.yml b/courses/csv404/quizz/155/question.yml new file mode 100644 index 00000000000..f0fb6e8fc54 --- /dev/null +++ b/courses/csv404/quizz/155/question.yml @@ -0,0 +1,7 @@ +id: "e887fb70-571d-42de-b8bd-32b4a3210325" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/156/en.yml b/courses/csv404/quizz/156/en.yml new file mode 100644 index 00000000000..ddd4c854889 --- /dev/null +++ b/courses/csv404/quizz/156/en.yml @@ -0,0 +1,9 @@ +question: "What three checks does the chapter recommend to verify a successful TAPD update?" +answer: "A successful `tapcli version` output, a healthy systemd status, and a quick `tapcli assets list` command" +wrong_answers: + - "A successful `tapd --check` output, a blockchain sync status above 99%, and a channel balance verification" + - "A matching SHA256 hash of the installed binary, a successful RPC ping, and a peer connection count above zero" + - "A successful `tapd validate` output, a log file review for migration errors, and a universe sync check" +explanation: >- + The chapter specifically lists three post-update verification steps: running `tapcli version` to confirm the new version is installed, checking the systemd service status to ensure TAPD is running healthily, and executing `tapcli assets list` to confirm that assets are accessible and everything is working correctly. +reviewed: false diff --git a/courses/csv404/quizz/156/question.yml b/courses/csv404/quizz/156/question.yml new file mode 100644 index 00000000000..5d820c5649f --- /dev/null +++ b/courses/csv404/quizz/156/question.yml @@ -0,0 +1,7 @@ +id: "0401d2e8-7270-4eb1-9bf9-22c937aa00b8" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/157/en.yml b/courses/csv404/quizz/157/en.yml new file mode 100644 index 00000000000..a30b6f62940 --- /dev/null +++ b/courses/csv404/quizz/157/en.yml @@ -0,0 +1,9 @@ +question: "Why does the chapter distinguish between the replaceability of binaries and the irreplaceability of data directories during a TAPD update?" +answer: "Because binaries can be re-downloaded or recompiled from source, but data directories contain unique wallet keys, channel state, and asset proofs that cannot be regenerated" +wrong_answers: + - "Because binaries are open-source and publicly auditable by anyone online, while data directories contain proprietary configuration that requires a paid license to restore fully" + - "Because binaries are cached locally by the operating system package manager, while data directories are encrypted with a one-time key derived at initial installation" + - "Because binaries are versioned and tracked in the Git repository history, while data directories are stored in an append-only format that can never be rolled back" +explanation: >- + The chapter emphasizes that binaries (tapd, tapcli) are replaceable because they can always be re-downloaded or recompiled. However, data directories (.tapd, .lnd, .bitcoin) contain your wallet private keys, Lightning channel state, asset proofs, and blockchain data. These are unique to your node and cannot be regenerated. Deleting them means permanent loss of access to your assets and channels. +reviewed: false diff --git a/courses/csv404/quizz/157/question.yml b/courses/csv404/quizz/157/question.yml new file mode 100644 index 00000000000..1ebb711d22a --- /dev/null +++ b/courses/csv404/quizz/157/question.yml @@ -0,0 +1,7 @@ +id: "3d3ae4b8-b4c6-4692-ac5b-7c41ab9dd3d3" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/158/en.yml b/courses/csv404/quizz/158/en.yml new file mode 100644 index 00000000000..cce0663e770 --- /dev/null +++ b/courses/csv404/quizz/158/en.yml @@ -0,0 +1,9 @@ +question: "According to the best practices, why should release candidates be avoided for production TAPD nodes?" +answer: "Release candidates are intended for testing only and may contain unresolved bugs that affect asset proofs or channel stability" +wrong_answers: + - "Release candidates lack digital signatures from Lightning Labs and cannot be verified for authenticity" + - "Release candidates automatically expire after 30 days and force a node restart that disrupts channel operations entirely" + - "Release candidates use a separate network protocol version that is incompatible with stable release nodes" +explanation: >- + The chapter advises using stable releases for production environments because release candidates are designated for testing only. Since each TAPD release can patch security vulnerabilities, fix bugs affecting asset proofs or channel stability, and introduce protocol changes, running unfinished release candidates in production risks exposing your node to issues that have not been fully vetted by the development and testing process. +reviewed: false diff --git a/courses/csv404/quizz/158/question.yml b/courses/csv404/quizz/158/question.yml new file mode 100644 index 00000000000..c1a4ab6d370 --- /dev/null +++ b/courses/csv404/quizz/158/question.yml @@ -0,0 +1,7 @@ +id: "c3d03ea9-d4cc-4c82-a608-ee4e344b63f6" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/159/en.yml b/courses/csv404/quizz/159/en.yml new file mode 100644 index 00000000000..54804605404 --- /dev/null +++ b/courses/csv404/quizz/159/en.yml @@ -0,0 +1,9 @@ +question: "What four reasons does the chapter give for why keeping TAPD up to date is essential?" +answer: "Patching security vulnerabilities, introducing required protocol features, fixing bugs in asset proofs or channel stability, and improving performance" +wrong_answers: + - "Maintaining strict API backward compatibility, reducing overall disk usage, enabling entirely new consensus rules, and supporting additional legacy asset types" + - "Complying with Lightning Network governance requirements, reducing memory consumption, adding new RPC endpoints, and enabling multi-sig support across nodes" + - "Meeting minimum version requirements for universe federation, enabling atomic swaps, patching DNS vulnerabilities, and adding REST API versioning support" +explanation: >- + The chapter explicitly lists four reasons to keep TAPD updated: each new release can patch security vulnerabilities, introduce protocol features required by the broader network, fix bugs that affect asset proofs or channel stability, and improve performance. These cover security, compatibility, reliability, and efficiency, making updates essential rather than optional. +reviewed: false diff --git a/courses/csv404/quizz/159/question.yml b/courses/csv404/quizz/159/question.yml new file mode 100644 index 00000000000..fb88d77a74b --- /dev/null +++ b/courses/csv404/quizz/159/question.yml @@ -0,0 +1,7 @@ +id: "5fda94a0-db69-42e1-91e7-adabfa32cb4f" +chapterId: "a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54" +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/160/en.yml b/courses/csv404/quizz/160/en.yml new file mode 100644 index 00000000000..fbbe5be03ff --- /dev/null +++ b/courses/csv404/quizz/160/en.yml @@ -0,0 +1,12 @@ +question: What is Lightning Terminal Daemon (LitD)? +answer: A single binary that bundles LND, TAPD, Loop, Pool, and Faraday into one unified service +wrong_answers: + - A graphical desktop application for managing Lightning channels and Taproot Assets + - A lightweight alternative to Bitcoin Core that only validates Taproot transactions + - A Docker container image that runs each Lightning service in separate microcontainers +explanation: >- + LitD is a unified binary that packages LND, TAPD, Loop, Pool, and Faraday together, + eliminating the need to manage three or more separate daemons. This contrasts with the + standalone approach covered in earlier chapters where Bitcoin Core, LND, and TAPD each + run as independent services. +reviewed: false diff --git a/courses/csv404/quizz/160/question.yml b/courses/csv404/quizz/160/question.yml new file mode 100644 index 00000000000..8f951f36e30 --- /dev/null +++ b/courses/csv404/quizz/160/question.yml @@ -0,0 +1,7 @@ +id: 5e81fd24-d167-450f-853b-0de69063c598 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/161/en.yml b/courses/csv404/quizz/161/en.yml new file mode 100644 index 00000000000..0e3e2ae6a38 --- /dev/null +++ b/courses/csv404/quizz/161/en.yml @@ -0,0 +1,12 @@ +question: What does the Stage 1 server security script do after creating a non-root user with sudo privileges? +answer: Configures SSH key-based authentication, disables root login over SSH, and disables password authentication +wrong_answers: + - Installs a firewall, enables automatic security updates, and configures fail2ban intrusion detection systems + - Generates TLS certificates, sets up a VPN tunnel, and creates fully encrypted disk partitions across the drive + - Configures two-factor authentication, installs antivirus software, and enables full audit logging on the system +explanation: >- + The Stage 1 script performs four specific hardening steps: creating a non-root user with sudo + privileges, configuring SSH key-based authentication, disabling root login over SSH, and disabling + password authentication. The chapter explicitly warns that SSH keys must be properly configured + before running this script, since disabling password auth without working keys will lock you out. +reviewed: false diff --git a/courses/csv404/quizz/161/question.yml b/courses/csv404/quizz/161/question.yml new file mode 100644 index 00000000000..728da7179e0 --- /dev/null +++ b/courses/csv404/quizz/161/question.yml @@ -0,0 +1,7 @@ +id: f1841bc6-4beb-44f5-83e2-712502904cca +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/162/en.yml b/courses/csv404/quizz/162/en.yml new file mode 100644 index 00000000000..665479dbe85 --- /dev/null +++ b/courses/csv404/quizz/162/en.yml @@ -0,0 +1,12 @@ +question: Which two approaches does the Stage 2 script offer for installing Bitcoin Core? +answer: Compiling from source for maximum transparency, or downloading a signed binary for faster deployment +wrong_answers: + - Installation via the system package manager, or downloading a pre-built Docker image from Docker Hub + - Cloning the Bitcoin Core GitHub repository via Git, or using a snap package from the Ubuntu store + - Downloading a precompiled static binary from bitcoincore.org, or building from a Nix flake definition +explanation: >- + The chapter specifies exactly two installation methods for Bitcoin Core in Stage 2: compiling from + source (which provides maximum transparency into what is being installed) and downloading a + precompiled binary with cryptographic signature verification (which is faster). Both methods + ensure authenticity, but through different trade-offs of speed versus auditability. +reviewed: false diff --git a/courses/csv404/quizz/162/question.yml b/courses/csv404/quizz/162/question.yml new file mode 100644 index 00000000000..872d09b17e9 --- /dev/null +++ b/courses/csv404/quizz/162/question.yml @@ -0,0 +1,7 @@ +id: 70937eec-20b2-47af-bebc-eda2aa29db11 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/163/en.yml b/courses/csv404/quizz/163/en.yml new file mode 100644 index 00000000000..805deccc1db --- /dev/null +++ b/courses/csv404/quizz/163/en.yml @@ -0,0 +1,12 @@ +question: Why is signet recommended as the network selection during Bitcoin Core configuration for development purposes? +answer: It mimics mainnet behavior but uses worthless test coins, making it ideal for development without financial risk +wrong_answers: + - It runs a local private blockchain with instant block confirmation, which speeds up testing cycles significantly + - It connects to the same network as mainnet but limits transaction sizes to prevent accidental large transfers + - It provides a shared mempool with mainnet so developers can test fee estimation against real transaction volumes +explanation: >- + Signet is recommended for development because it closely replicates mainnet behavior while using + test coins that have no monetary value. Unlike regtest, which is a private local chain, signet is + a shared public test network with realistic block times and mining behavior. This makes it suitable + for testing Taproot Assets workflows in conditions that closely approximate production. +reviewed: false diff --git a/courses/csv404/quizz/163/question.yml b/courses/csv404/quizz/163/question.yml new file mode 100644 index 00000000000..0690491fbb0 --- /dev/null +++ b/courses/csv404/quizz/163/question.yml @@ -0,0 +1,7 @@ +id: 180fce1e-b952-4125-bc9b-bf31822ecfa9 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/164/en.yml b/courses/csv404/quizz/164/en.yml new file mode 100644 index 00000000000..6821f9412c8 --- /dev/null +++ b/courses/csv404/quizz/164/en.yml @@ -0,0 +1,12 @@ +question: What dependencies does Stage 3 install before compiling LitD from source? +answer: Go, Node.js, and Yarn tooling +wrong_answers: + - Rust, Python, and pip + - Go, Docker, and Make + - Clang, CMake, and Protobuf +explanation: >- + Stage 3 specifically installs Go, Node.js, and Yarn as the required dependencies before running + make install to compile LitD. Go is the primary language LitD is written in, while Node.js and + Yarn are needed for the web-based UI components bundled with Lightning Terminal. The compilation + process typically takes 5 to 10 minutes. +reviewed: false diff --git a/courses/csv404/quizz/164/question.yml b/courses/csv404/quizz/164/question.yml new file mode 100644 index 00000000000..fc160d136a4 --- /dev/null +++ b/courses/csv404/quizz/164/question.yml @@ -0,0 +1,7 @@ +id: 05077971-ffcc-43d3-ac69-598e85b5f783 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/165/en.yml b/courses/csv404/quizz/165/en.yml new file mode 100644 index 00000000000..99105a85294 --- /dev/null +++ b/courses/csv404/quizz/165/en.yml @@ -0,0 +1,12 @@ +question: What is the correct sequence for initially creating a wallet with LitD? +answer: Start LitD manually, run lncli create in a separate terminal, set a password, and record the seed phrase +wrong_answers: + - Run litd --create-wallet from the command line, enter a password when prompted, and import an existing seed phrase + - Use the LitD web interface to generate a new wallet, download the seed backup file, and restart the service + - Execute tapcli wallet init to initialize all wallets simultaneously, then configure the password file +explanation: >- + The chapter describes a specific sequence: first start LitD manually in one terminal, then open a + separate terminal to run lncli create, set a wallet password, and securely record the 24-word seed + phrase. This two-terminal approach is necessary because LitD must be running before the wallet + creation command can connect to it. +reviewed: false diff --git a/courses/csv404/quizz/165/question.yml b/courses/csv404/quizz/165/question.yml new file mode 100644 index 00000000000..d3a71fa4eea --- /dev/null +++ b/courses/csv404/quizz/165/question.yml @@ -0,0 +1,7 @@ +id: 4de29558-49d0-4081-bdd7-87216aa95684 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/166/en.yml b/courses/csv404/quizz/166/en.yml new file mode 100644 index 00000000000..bb5a9e2df96 --- /dev/null +++ b/courses/csv404/quizz/166/en.yml @@ -0,0 +1,12 @@ +question: How is automatic wallet unlocking configured for a production LitD deployment? +answer: Write the wallet password to a chmod-600 file and reference it in lit.conf via lnd.wallet-unlock-password-file +wrong_answers: + - Store the wallet password in an environment variable and pass it to the systemd service file via the Environment directive + - Use lncli unlock --auto to enable the built-in keyring integration with the operating system's credential manager + - Configure a pre-start hook in the systemd service that pipes the password from a hardware security module into stdin +explanation: >- + The chapter shows the exact production setup: write the password to ~/.lit/wallet-password, restrict + its permissions with chmod 600, and add the lnd.wallet-unlock-password-file directive pointing to + that file in lit.conf. This allows the systemd service to automatically unlock the wallet on + startup without manual intervention while keeping the password file access-restricted. +reviewed: false diff --git a/courses/csv404/quizz/166/question.yml b/courses/csv404/quizz/166/question.yml new file mode 100644 index 00000000000..f7924d71d77 --- /dev/null +++ b/courses/csv404/quizz/166/question.yml @@ -0,0 +1,7 @@ +id: c95db533-6441-498e-bd66-7825e98609f9 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/167/en.yml b/courses/csv404/quizz/167/en.yml new file mode 100644 index 00000000000..126f0173678 --- /dev/null +++ b/courses/csv404/quizz/167/en.yml @@ -0,0 +1,13 @@ +question: Which five verification commands confirm that a LitD node is fully operational after installation? +answer: litcli status, lncli getinfo, tapcli assets list, tapcli universe federation list, and sudo systemctl status litd +wrong_answers: + - litd --check, lncli walletbalance, tapcli universe info, systemctl is-active litd, and bitcoin-cli getblockchaininfo + - lncli getinfo, lncli channels, tapcli assets balance, tapcli addrs list, and journalctl -u litd + - litcli health, bitcoin-cli getnetworkinfo, lncli pendingchannels, tapcli universe roots, and systemctl list-units litd +explanation: >- + The chapter lists exactly five verification commands: litcli status (all services running), + lncli getinfo (LND synced to chain), tapcli assets list (TAPD responding, with an empty list + expected on a fresh node), tapcli universe federation list (universe connectivity), and + sudo systemctl status litd (systemd health). All five must pass for the node to be considered + fully operational. +reviewed: false diff --git a/courses/csv404/quizz/167/question.yml b/courses/csv404/quizz/167/question.yml new file mode 100644 index 00000000000..f58419c4ba1 --- /dev/null +++ b/courses/csv404/quizz/167/question.yml @@ -0,0 +1,7 @@ +id: d6f61fa7-f503-4e74-b8e9-c5b12ef1c770 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/168/en.yml b/courses/csv404/quizz/168/en.yml new file mode 100644 index 00000000000..e8f26c21f1e --- /dev/null +++ b/courses/csv404/quizz/168/en.yml @@ -0,0 +1,13 @@ +question: Why does the chapter warn against blindly executing the Run LITD scripts on a production server? +answer: The scripts target developers spinning up quick test environments, so automated scripts need line-by-line review before production use +wrong_answers: + - The scripts contain hardcoded testnet configurations that would cause a production node to silently connect to the wrong network entirely + - The scripts install outdated dependency versions that have known critical security vulnerabilities in most production environments + - The scripts require full root access and disable the firewall, which permanently weakens the entire server's security posture +explanation: >- + The chapter includes an explicit caveat that the Run LITD scripts are built for developers who + need to spin up testing environments fast. The warning is about operational discipline: never + blindly execute automated scripts on a production server without reviewing every line. This is + a general security principle, as automated deployment scripts may make assumptions that are + inappropriate for a production environment with real funds. +reviewed: false diff --git a/courses/csv404/quizz/168/question.yml b/courses/csv404/quizz/168/question.yml new file mode 100644 index 00000000000..85bd6703353 --- /dev/null +++ b/courses/csv404/quizz/168/question.yml @@ -0,0 +1,7 @@ +id: ff737d00-61c9-4611-bcae-efe744eba760 +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/169/en.yml b/courses/csv404/quizz/169/en.yml new file mode 100644 index 00000000000..f58f90d1b05 --- /dev/null +++ b/courses/csv404/quizz/169/en.yml @@ -0,0 +1,12 @@ +question: What does the Stage 2 Bitcoin Core script generate for communication between Bitcoin Core and LND? +answer: A secure RPC credential string that LND uses to authenticate with Bitcoin Core's interface +wrong_answers: + - A TLS certificate pair that encrypts all traffic between the two services over a local socket + - A shared macaroon file that grants LND read-only access to Bitcoin Core wallet functions + - A Unix domain socket configuration that allows direct memory-mapped communication between processes +explanation: >- + The Stage 2 script generates a secure RPC credential string specifically for LND to communicate + with Bitcoin Core. This credential is written into bitcoin.conf and later referenced in the + LitD configuration during Stage 3. RPC credentials are the standard authentication mechanism + for external programs to interact with Bitcoin Core's JSON-RPC interface. +reviewed: false diff --git a/courses/csv404/quizz/169/question.yml b/courses/csv404/quizz/169/question.yml new file mode 100644 index 00000000000..d6f175573b0 --- /dev/null +++ b/courses/csv404/quizz/169/question.yml @@ -0,0 +1,7 @@ +id: eddc7baa-4cb5-403f-9e96-0cee3785623d +chapterId: 992d8650-87f2-11f0-aace-9be7f0fb0b83 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/170/en.yml b/courses/csv404/quizz/170/en.yml new file mode 100644 index 00000000000..147c13279bf --- /dev/null +++ b/courses/csv404/quizz/170/en.yml @@ -0,0 +1,12 @@ +question: What is an edge node in the context of Taproot Assets Lightning payments? +answer: A Lightning node that maintains channels in at least two different asset types to bridge cross-asset payments +wrong_answers: + - A lightweight node that only validates Taproot Asset proofs without participating in payment routing at all + - A node positioned at the network periphery that caches asset metadata for faster proof verification lookups + - A specialized mining node that produces blocks containing both Bitcoin and Taproot Asset transactions directly +explanation: >- + An edge node holds channels denominated in at least two different asset types, such as a stablecoin + channel on one side and a Bitcoin channel on the other. This positioning allows it to absorb one + asset and release another, acting as a bridge that enables cross-asset payments without requiring + both sender and receiver to hold the same asset. +reviewed: false diff --git a/courses/csv404/quizz/170/question.yml b/courses/csv404/quizz/170/question.yml new file mode 100644 index 00000000000..82edafb62d2 --- /dev/null +++ b/courses/csv404/quizz/170/question.yml @@ -0,0 +1,7 @@ +id: 9f9732b1-fe55-4c82-8991-6456fa476e9e +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/171/en.yml b/courses/csv404/quizz/171/en.yml new file mode 100644 index 00000000000..dbf62aac923 --- /dev/null +++ b/courses/csv404/quizz/171/en.yml @@ -0,0 +1,12 @@ +question: In the cross-asset payment scenario described in the chapter, what happens when Alice (holding stablecoins) pays Bob's Bitcoin Lightning invoice? +answer: Alice sends stablecoins to the edge node, which converts them and forwards the corresponding bitcoin amount to Bob +wrong_answers: + - Alice's node automatically swaps her stablecoins for bitcoin on a decentralized exchange before sending the payment + - Bob's node accepts the stablecoins directly and converts them to bitcoin using its built-in atomic swap capability + - The Lightning Network routes the stablecoins through intermediate nodes that each perform partial conversions +explanation: >- + The edge node serves as the bridge in this transaction. Alice sends stablecoins to the edge node + on one side, and the edge node releases the equivalent bitcoin amount to Bob on the other side. + Alice never needs to own bitcoin, and Bob never sees stablecoins. The conversion happens entirely + at the edge node. +reviewed: false diff --git a/courses/csv404/quizz/171/question.yml b/courses/csv404/quizz/171/question.yml new file mode 100644 index 00000000000..a52dbe71a96 --- /dev/null +++ b/courses/csv404/quizz/171/question.yml @@ -0,0 +1,7 @@ +id: 99957b81-60c8-4f44-a215-57b3ffd5e648 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/172/en.yml b/courses/csv404/quizz/172/en.yml new file mode 100644 index 00000000000..c15b877d7d3 --- /dev/null +++ b/courses/csv404/quizz/172/en.yml @@ -0,0 +1,13 @@ +question: What is the correct sequence of steps in the RFQ (Request for Quote) system? +answer: Alice's node recognizes it needs bitcoin, sends an RFQ to the edge node, which consults its price oracle, returns a quote, and Alice's node accepts or rejects it +wrong_answers: + - Alice's node broadcasts a price request to every connected peer on the network, collects all competing quotes, selects the single best available rate, and initiates the payment + - The edge node periodically publishes exchange rates to the entire peer-to-peer network, and Alice's node uses the most recently cached rate for the payment + - Alice's node queries a global on-chain price feed smart contract, calculates the conversion locally, and sends the exact stablecoin amount required +explanation: >- + The RFQ system follows a specific five-step flow: Alice's node receives Bob's invoice and + recognizes it only holds stablecoins, sends an RFQ request to the edge node, the edge node + consults its price oracle for the current rate, returns a quote with the exact stablecoin amount, + and Alice's node evaluates and accepts or rejects it. This entire negotiation happens in + milliseconds before the payment is routed. +reviewed: false diff --git a/courses/csv404/quizz/172/question.yml b/courses/csv404/quizz/172/question.yml new file mode 100644 index 00000000000..b3a0b7ad06c --- /dev/null +++ b/courses/csv404/quizz/172/question.yml @@ -0,0 +1,7 @@ +id: fe23df6d-4e30-4037-9554-cf247948747d +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/173/en.yml b/courses/csv404/quizz/173/en.yml new file mode 100644 index 00000000000..39d28d6e487 --- /dev/null +++ b/courses/csv404/quizz/173/en.yml @@ -0,0 +1,12 @@ +question: What does a decimal display value of 6 mean for a USD stablecoin in the price oracle's configuration? +answer: One dollar equals exactly 1,000,000 base units, which enables sub-cent precision in cross-asset calculations +wrong_answers: + - The oracle rounds all exchange rate calculations to six decimal places before returning a quote + - The stablecoin supports a maximum of six digits in its total supply, limiting issuance to 999,999 tokens + - Price quotes are cached for six seconds before the oracle fetches a fresh rate from external feeds +explanation: >- + The decimal display defines how the smallest on-chain unit relates to the human-readable value. + With a decimal display of 6, one dollar is represented as 1,000,000 base units (10^6). This + granularity allows the system to handle amounts smaller than one cent, which is essential for + precise exchange rate calculations and preventing rounding errors in cross-asset payments. +reviewed: false diff --git a/courses/csv404/quizz/173/question.yml b/courses/csv404/quizz/173/question.yml new file mode 100644 index 00000000000..e64b455f69b --- /dev/null +++ b/courses/csv404/quizz/173/question.yml @@ -0,0 +1,7 @@ +id: 0049e91a-1232-478e-a680-aafcc5e75459 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/174/en.yml b/courses/csv404/quizz/174/en.yml new file mode 100644 index 00000000000..c997b76422c --- /dev/null +++ b/courses/csv404/quizz/174/en.yml @@ -0,0 +1,13 @@ +question: Why are group keys especially useful for stablecoins in the price oracle's asset registry? +answer: They allow the oracle to support stablecoins that have undergone multiple minting rounds under a single identifier +wrong_answers: + - They enable the oracle to aggregate prices from multiple exchange feeds and compute a weighted average rate across sources + - They provide cryptographic proof that the stablecoin issuer has sufficient reserves backing each token issued + - They allow multiple oracles to share a common signing key so quotes can be verified across the entire network +explanation: >- + A stablecoin issuer may mint new tokens in multiple batches over time, with each batch producing a + different asset ID. Group keys solve this by grouping all minting rounds of the same stablecoin + under one identifier. The price oracle's asset registry can then reference the group key to + recognize and price all batches of that stablecoin uniformly, rather than needing a separate + entry for each individual minting event. +reviewed: false diff --git a/courses/csv404/quizz/174/question.yml b/courses/csv404/quizz/174/question.yml new file mode 100644 index 00000000000..6ad31027444 --- /dev/null +++ b/courses/csv404/quizz/174/question.yml @@ -0,0 +1,7 @@ +id: 5dfbc88f-aebb-458d-af42-9bb125ba5ab7 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/175/en.yml b/courses/csv404/quizz/175/en.yml new file mode 100644 index 00000000000..8d8b911cc08 --- /dev/null +++ b/courses/csv404/quizz/175/en.yml @@ -0,0 +1,12 @@ +question: How is the price oracle connected to a LitD node? +answer: By setting taproot-assets.experimental.rfq.priceoracleaddress in lit.conf to the oracle's host and port +wrong_answers: + - By running tapcli oracle register with the oracle's public key and gRPC endpoint as arguments + - By placing the oracle binary in the same directory as LitD so it is automatically discovered at startup + - By configuring a mutual TLS certificate exchange between the oracle and LitD using the lncli connect command +explanation: >- + The chapter shows that connecting the oracle requires a single configuration line in lit.conf: + taproot-assets.experimental.rfq.priceoracleaddress=localhost:8095. For a remote oracle, localhost + is replaced with the server's IP address. This directive tells TAPD where to send RFQ price + queries when it needs to calculate exchange rates for cross-asset payments. +reviewed: false diff --git a/courses/csv404/quizz/175/question.yml b/courses/csv404/quizz/175/question.yml new file mode 100644 index 00000000000..eb236255ccf --- /dev/null +++ b/courses/csv404/quizz/175/question.yml @@ -0,0 +1,7 @@ +id: d1a65734-15b4-498f-b642-0bec4f6e9f10 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/176/en.yml b/courses/csv404/quizz/176/en.yml new file mode 100644 index 00000000000..1f1f9dfa655 --- /dev/null +++ b/courses/csv404/quizz/176/en.yml @@ -0,0 +1,13 @@ +question: What role do scaling factors play in the price oracle's exchange rate calculations? +answer: They provide additional internal precision during calculations to help prevent cumulative floating-point rounding errors +wrong_answers: + - They adjust the exchange rate based on network congestion to account for higher on-chain fee costs + - They multiply the quoted price by a configurable margin percentage to ensure the edge node earns a profit + - They normalize asset amounts across different blockchains so cross-chain swaps use consistent unit sizes +explanation: >- + Scaling factors add extra digits of precision internally during the mathematical conversion + between asset types. This prevents floating-point rounding errors that could accumulate during + division and multiplication operations, which is critical when dealing with large amounts or + assets with very different unit scales. The scaling is applied during calculation only and does + not affect the final quoted amounts presented to the user. +reviewed: false diff --git a/courses/csv404/quizz/176/question.yml b/courses/csv404/quizz/176/question.yml new file mode 100644 index 00000000000..dcedf124432 --- /dev/null +++ b/courses/csv404/quizz/176/question.yml @@ -0,0 +1,7 @@ +id: 63779321-1ce4-4166-bd50-093f8ea99a75 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/177/en.yml b/courses/csv404/quizz/177/en.yml new file mode 100644 index 00000000000..e234dbafc77 --- /dev/null +++ b/courses/csv404/quizz/177/en.yml @@ -0,0 +1,12 @@ +question: Which parameters are required when creating an invoice for a cross-asset payment using litcli? +answer: The amount in millisatoshis, the asset group key, and the RFQ peer's public key for the edge node +wrong_answers: + - The amount in the destination asset, the sender's channel ID, and the oracle's gRPC endpoint + - The asset ID, the recipient's node public key, and the desired exchange rate ceiling + - The payment hash, the asset decimal display value, and the routing hop count to the edge node +explanation: >- + The chapter shows the exact command: litcli invoices addholdinvoice --amt_msat --asset_group_key + --rfq_peer_pubkey. The amount is specified in millisatoshis, the asset group key identifies which + Taproot Asset to use, and the rfq_peer_pubkey tells the system which edge node to request a + quote from. These three parameters together enable the RFQ negotiation for cross-asset payment. +reviewed: false diff --git a/courses/csv404/quizz/177/question.yml b/courses/csv404/quizz/177/question.yml new file mode 100644 index 00000000000..e33eae5e51c --- /dev/null +++ b/courses/csv404/quizz/177/question.yml @@ -0,0 +1,7 @@ +id: b851b2c7-6f9a-4c0a-879f-f1bcfbca5219 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: hard +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/178/en.yml b/courses/csv404/quizz/178/en.yml new file mode 100644 index 00000000000..3bfb9323877 --- /dev/null +++ b/courses/csv404/quizz/178/en.yml @@ -0,0 +1,13 @@ +question: What are the four production considerations the chapter recommends for running a price oracle? +answer: Using multiple price feeds, defining asset support policies, implementing comprehensive logging, and setting up monitoring with alerting +wrong_answers: + - Enabling rate limiting, configuring mutual TLS, deploying redundant oracle instances, and auditing smart contract logic + - Caching exchange rates for efficiency, rotating API keys daily, backing up the oracle database hourly, and limiting quote validity to one second + - Running the oracle in a Docker container, load-balancing across regions, encrypting all RFQ messages, and publishing rate history on-chain +explanation: >- + The chapter lists four specific production considerations: querying at least two or three + independent price sources, only supporting assets whose market dynamics you understand, logging + every quote, price fetch, and calculation, and setting up alerts for oracle downtime or price + feed failures. These measures ensure reliability and auditability for a production edge node + handling real-value cross-asset conversions. +reviewed: false diff --git a/courses/csv404/quizz/178/question.yml b/courses/csv404/quizz/178/question.yml new file mode 100644 index 00000000000..cf6837bf8d3 --- /dev/null +++ b/courses/csv404/quizz/178/question.yml @@ -0,0 +1,7 @@ +id: 9ac7281e-6d58-4e9b-af51-061df4682224 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: easy +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/quizz/179/en.yml b/courses/csv404/quizz/179/en.yml new file mode 100644 index 00000000000..750d0d9ebe7 --- /dev/null +++ b/courses/csv404/quizz/179/en.yml @@ -0,0 +1,13 @@ +question: How can the accuracy of a price oracle's conversion be independently verified after a cross-asset payment? +answer: By checking oracle logs for the exact Bitcoin price used and cross-checking the conversion math in a spreadsheet +wrong_answers: + - By querying the full on-chain transaction directly and comparing the input and output values in a block explorer + - By running tapcli oracle verify with the payment hash to trigger an automated audit of the full conversion + - By comparing the payment preimage against the oracle's signed rate commitment stored in the channel state data +explanation: >- + The chapter describes two verification methods: examining oracle logs (which show the exact Bitcoin + price used, timestamps, and calculations) and performing spreadsheet verification (entering the + reported price, asset amounts, and decimal display to independently calculate the expected + conversion and compare with actual channel balance changes). This dual approach provides both + operational and mathematical confirmation of oracle accuracy. +reviewed: false diff --git a/courses/csv404/quizz/179/question.yml b/courses/csv404/quizz/179/question.yml new file mode 100644 index 00000000000..3e208406bcf --- /dev/null +++ b/courses/csv404/quizz/179/question.yml @@ -0,0 +1,7 @@ +id: 614b71bf-d06e-425d-be12-d29c38b4e726 +chapterId: b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 +difficulty: intermediate +duration: 15 +author: plan-b-network +tags: [] +original_language: en diff --git a/courses/csv404/rn.md b/courses/csv404/rn.md deleted file mode 100644 index 1bd19511d5a..00000000000 --- a/courses/csv404/rn.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Iciyumviro: Amavidewo y'iri somo aboneka mu congereza gusa. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/ru.md b/courses/csv404/ru.md deleted file mode 100644 index bfd1ca64218..00000000000 --- a/courses/csv404/ru.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Примечание: Видео к этому курсу доступны только на английском языке. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/sr-Latn.md b/courses/csv404/sr-Latn.md deleted file mode 100644 index 464523022bf..00000000000 --- a/courses/csv404/sr-Latn.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Napomena: Video snimci za ovaj kurs dostupni su samo na engleskom jeziku. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/sv.md b/courses/csv404/sv.md deleted file mode 100644 index f1472ea91d4..00000000000 --- a/courses/csv404/sv.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Obs: Videorna för denna kurs är endast tillgängliga på engelska. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/sw.md b/courses/csv404/sw.md deleted file mode 100644 index 2f3f3b1a57d..00000000000 --- a/courses/csv404/sw.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Kumbuka: Video za kozi hii zinapatikana kwa Kiingereza pekee. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/tr.md b/courses/csv404/tr.md deleted file mode 100644 index 9b1936d666e..00000000000 --- a/courses/csv404/tr.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Not: Bu kursun videoları yalnızca İngilizce olarak mevcuttur. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/vi.md b/courses/csv404/vi.md deleted file mode 100644 index 47a1de7710e..00000000000 --- a/courses/csv404/vi.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -Lưu ý: Video của khóa học này chỉ có sẵn bằng tiếng Anh. - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/zh-Hans.md b/courses/csv404/zh-Hans.md deleted file mode 100644 index 89cf2dc4340..00000000000 --- a/courses/csv404/zh-Hans.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -注意：本课程的视频仅提供英文版本。 - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - - diff --git a/courses/csv404/zh-Hant.md b/courses/csv404/zh-Hant.md deleted file mode 100644 index abca5606dd7..00000000000 --- a/courses/csv404/zh-Hant.md +++ /dev/null @@ -1,695 +0,0 @@ ---- -name: Tapping into Taproot Assets -goal: Master the Taproot Assets Protocol for multi-asset Bitcoin and Lightning -objectives: - - Understand the cryptographic foundations and architecture of Taproot Assets - - Install and configure TAPD with LND for production environments - - Create, transfer, and manage assets on Bitcoin and Lightning - - Implement universe federation and proof distribution systems - - Build and deploy Taproot Assets applications with advanced features ---- - -# Tapping into Taproot Assets - -Explore the groundbreaking Taproot Assets Protocol (TAP), enabling native multi-asset functionality on Bitcoin and the Lightning Network. This comprehensive technical course takes you from cryptographic foundations through production deployment, covering everything needed to mint, transfer, and manage digital assets using Bitcoin's security model. - -Through hands-on implementation and real-world examples, you'll master the MerkleSum Sparse Merkle Tree structures, understand client-side validation, and learn to leverage Taproot's privacy features for scalable asset management. Deploy production-ready TAP nodes, integrate with Lightning channels for instant asset transfers, and build applications using the comprehensive API ecosystem. - -Whether you're building stablecoins, NFTs, or custom financial instruments, this course provides the technical depth and practical skills to leverage Taproot Assets for next-generation Bitcoin applications. - -注意：本課程的視頻僅提供英文版本。 - -+++ - -# Introduction -f8d4a3c7-9b2e-4e5f-a1d3-8c6f9e2b4a15 - -## Course presentation -a2e5f8b9-4c3d-41e7-b9f2-6d8a3c5e9f14 - -Welcome to this advanced technical course on Taproot Assets, designed for experienced developers ready to extend Bitcoin's capabilities into multi-asset protocols. This course provides comprehensive coverage of the Taproot Assets Protocol from theoretical foundations to production deployment. - -**Section 1: Protocol Foundations** - -The first section explores the cryptographic architecture underlying Taproot Assets. You'll understand how MerkleSum Sparse Merkle Trees enable efficient proof systems, how assets are embedded within Bitcoin transactions, and how the protocol maintains privacy while enabling verification. We cover the integration with Lightning Network for instant transfers and the universe system for proof distribution. - -**Section 2: Installation and Configuration** - -The second section focuses on practical deployment. You'll learn multiple installation methods including source compilation, binary deployment, and integration with Lightning Terminal (LitD). We cover both development environments using Polar and production configurations with proper security and system integration. - -**Section 3: Operations and Development** - -The third section covers asset operations from CLI and API perspectives. You'll master minting fungible and non-fungible assets, executing on-chain and Lightning transfers, and managing asset lifecycles including burns. We explore the comprehensive API architecture including REST and gRPC interfaces. - -**Section 4: Advanced Topics** - -The final section addresses production concerns including running price oracles, managing universe federations, building nodes from scratch, and maintaining TAPD installations. You'll learn to build applications leveraging PSBTs for complex multi-party operations. - -This course emphasizes hands-on implementation with real code examples, API interactions, and troubleshooting guidance for production deployments. - -# The Taproot Asset Protocol -d7f9e2c4-3a5b-4f8e-9c1d-2b6a8e5f3d17 -## Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning -b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16 - -:::video id=f45eeea0-6583-498b-af6a-c148cbe0ed00::: - -### Understanding Taproot Asset - -The [Taproot](https://planb.academy/resources/glossary/taproot) Asset (orginally Taproot Asset Representation Overlay aka Taro) represents a groundbreaking advancement in Bitcoin's capabilities, introducing a new Taproot-powered protocol for issuing assets directly on the Bitcoin [blockchain](https://planb.academy/resources/glossary/blockchain). What makes Taproot Asset particularly revolutionary is its ability to enable these assets to be transferred seamlessly over the [Lightning Network](https://planb.academy/resources/glossary/lightning-network), combining the security of Bitcoin's base layer with the speed and efficiency of Lightning payments. - -Since Taproot Asset is fundamentally powered by Taproot, understanding this protocol requires a solid foundation in Taproot's mechanics and capabilities. The integration with Taproot is not merely technical convenience but rather the cornerstone that enables Taproot Asset's unique approach to asset representation and transfer. This Taproot foundation allows Taproot Asset to leverage Bitcoin's existing security model while introducing new functionality that was previously impossible. - -Taproot assets can be conceptualized as specialized [UTXOs](https://planb.academy/resources/glossary/utxo) that exist within a Bitcoin Taproot UTXO, creating a nested structure that maintains Bitcoin's security guarantees while enabling new asset types. This architectural approach means that creating Taproot assets requires only a single on-chain Taproot transaction, with no theoretical limit to the number of assets that can be created within that single transaction. The creation process embeds asset information directly into Bitcoin transactions in a way that makes them indistinguishable from regular Taproot transactions to outside observers, maintaining privacy while enabling expanded capabilities. - -### MerkleSum as cryptographic foundation - -Taproot Asset employs a sophisticated data structure called the MerkleSum Sparse [Merkle Tree](https://planb.academy/resources/glossary/merkle-tree), which combines multiple cryptographic concepts to achieve the protocol's security and efficiency goals. When spending a Taproot asset, users must prove ownership through a Merkle tree inclusion proof, demonstrating that their asset exists within the committed tree structure. However, Taproot Asset's requirements extend beyond simple inclusion proofs—the protocol must also demonstrate that spending transactions properly relinquish ownership of assets, which requires proving the absence of data rather than its presence. - -Sparse Merkle Trees solve the challenge of proving data absence by storing objects at leaf locations defined by the binary expression of the [SHA-256](https://planb.academy/resources/glossary/sha256) digest of that data. This deterministic placement means that any object can produce the exact route to where it would be located in the tree if it were present. When an asset is spent or transferred, the protocol can prove that the asset has been removed from its expected location without revealing the entire tree structure. - -The "Sum" aspect introduces additional security guarantees specifically designed for asset protocols. In a Merkle Sum Tree, each leaf contains numeric values representing asset quantities, and each internal node carries the sum of all values in its subtree. The root of the tree therefore contains the total sum of all assets within the entire structure. This summation property provides crucial anti-inflation guarantees—by examining the root sum, validators can efficiently verify that assets stored in the tree haven't been artificially inflated without needing to examine every individual asset. - -The complete MerkleSum Sparse Merkle Tree structure integrates seamlessly with Bitcoin's Taproot functionality through a process that embeds the tree root into a Taproot tree leaf. Using the tap tweak mechanism, the protocol commits to the tree root within the transaction itself, creating an unbreakable cryptographic link between the Bitcoin transaction and the Taproot asset data. - -### Lightning Network Integration and Asset Transfers - -The integration of fungible Taproot assets with the Lightning Network represents one of the protocol's most compelling features. To send a particular Taproot asset over Lightning, both the sending and receiving [nodes](https://planb.academy/resources/glossary/node) must have Taproot Asset-enabled channels that hold the specific asset being transferred. However, all intermediate channels in the payment route do not need to hold or even be aware of the Taproot assets being transferred. This routing capability enables powerful use cases where Alice could route a Lightning USD asset through Bob, Carol, and potentially many other intermediate nodes before reaching Dan, with only the channels at the payment's endpoints needing awareness of the Taproot asset. - -Transferring Taproot assets on-chain requires reorganizing the underlying Merkle tree structure and publishing a new on-chain transaction that commits to the updated tree root. However, the protocol supports unlimited internal Taproot Asset transactions within a single on-chain Bitcoin transaction, providing significant scalability benefits. When Taproot assets need to be sent to different Taproot key holders, the protocol employs an asset split mechanism. The sender updates their own MerkleSum Sparse Merkle Tree by adjusting balances and recalculating the [Merkle root](https://planb.academy/resources/glossary/merkle-root) to reflect the outgoing transfer, while simultaneously, a second MerkleSum Sparse Merkle Tree is committed to a new Taproot output controlled by the receiver. - -Beyond simple asset transfers, the Lightning Network integration supports automatic asset exchange functionality. Lightning invoices can be paid or received using Taproot assets, with automatic conversion to Bitcoin handled by either party in the transaction. This capability opens possibilities for seamless cross-asset payments where users can pay Lightning invoices denominated in Bitcoin using their Taproot asset holdings, or vice versa. The automatic exchange mechanism abstracts away much of the complexity involved in multi-asset Lightning payments, providing user experiences that feel natural while leveraging the underlying technical sophistication of the Taproot Asset protocol. - -Universe services play a crucial supporting role by providing information about assets and maintaining proofs for asset holders. These services function similarly to Bitcoin block explorers but specialize in showcasing Taproot Asset transaction data, which is stored off-chain with Taproot Asset clients rather than directly on the Bitcoin blockchain. By keeping detailed transaction histories off-chain while maintaining cryptographic commitments on-chain, the protocol achieves scalability benefits without sacrificing security. - - -## Taproot Assets Demo -e6f3a8d1-9c2b-4e7f-b5a8-3d1c6f9e8b27 - -:::video id=aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec::: - -### Introduction to Taproot Asset Client - -The Taproot Asset client represents a significant advancement in Bitcoin's capability to handle digital assets, and it is now publicly available for developers and enthusiasts to explore. This chapter will guide you through the complete process of downloading, installing, configuring, and operating Taproot Asset, providing you with the foundational knowledge needed to begin working with this innovative technology. As Taproot Asset continues to evolve rapidly, it's essential to approach this new technology with appropriate caution and stay updated with the latest developments and documentation. - -Before diving into the installation process, you must ensure your system meets the necessary prerequisites for running Taproot Asset effectively. The most critical requirement is establishing a connection to a Lightning Network Daemon (LND) node, as Taproot Asset operates as a layer built on top of the Lightning Network infrastructure. While it's technically possible to connect Taproot Asset to a remote LND node, the simplest and most straightforward approach involves connecting it to a node running on the same machine where you plan to install Taproot Asset. - -For installation from source code, which provides the most flexibility and up-to-date features, you'll need Go version 1.18 or greater installed on your system. The installation process will create two primary binaries that form the core of the Taproot Asset system: the Taproot Asset daemon (taro-d) and the command-line interface tool (taro-cli). For initial experimentation and development work, connecting Taproot Asset to a regtest network via Polar provides an excellent sandbox environment where you can safely test operations without using real Bitcoin. - -### Installation and Configuration - -The installation process begins with cloning the Taproot Asset repository from GitHub, which can be found at [github.com/lightninglabs/taro](https://github.com/lightninglabs/taproot-assets). Once you've cloned the repository to your chosen directory, navigate into the project directory and execute the `make install` command. This command handles the entire build process, compiling the Go source code and placing the resulting binaries in your system's Go path. Upon successful completion, you should have two essential binaries available: taro-d (the Taproot Asset daemon) and taro-cli (the command-line interface tool). - -When you first start the Taproot Asset daemon, it automatically creates a `.taro` directory in your home directory to store all Taproot Asset-related data, including configuration files, database files, and other operational data. While the system can operate with default settings, you have the option to create a custom configuration file named `taro.conf` within the `.taro` directory to specify particular settings and preferences. The configuration file is not mandatory for basic operations, as you can provide all necessary configuration parameters directly through command-line arguments when starting the daemon. - -Starting the Taproot Asset daemon requires providing several key pieces of information to establish proper communication with your LND node. The startup command must specify the network type (such as testnet), set appropriate debug levels for troubleshooting and monitoring, and provide the network address and port where LND is listening for connections. Additionally, the daemon needs to know the locations of two critical LND files: the admin macaroon, which provides authentication credentials for accessing LND's administrative functions, and the TLS certificate, which ensures secure communication between Taproot Asset and LND. - -Once properly configured and started, the Taproot Asset daemon will begin listening on its default ports, typically 10029 and 8089, for various types of connections and communications. For production environments or continuous operation, you may want to consider setting up a systemd service or configuring a crontab entry to ensure the Taproot Asset daemon starts automatically and remains running even after system restarts. - -### Asset Operations and Transfers - -The process of creating new assets with Taproot Asset begins with the asset minting operation, which represents one of the most fundamental capabilities of the system. Using the taro-cli command-line tool, you can mint assets by specifying several key parameters that define the characteristics and properties of your new digital asset. The minting command requires you to specify the asset type (typically "normal" for standard assets), provide a unique name for your asset, and define the total supply or quantity of the asset you wish to create. - -When minting assets, you can choose to use the "skip batch" option, which instructs Taproot Asset to immediately process the minting operation rather than waiting to group multiple asset creation requests together. After successfully minting assets, you can verify the operation's success and review your asset holdings using the `assets list` command, which provides a comprehensive overview of all assets associated with your Taproot Asset instance, including details such as asset names, quantities, and other relevant metadata. - -Taproot Asset supports various types of asset transfer operations, with the "split" operation being one of the most common and useful for everyday transactions. A split operation allows you to send a portion of your asset holdings to another party while retaining the remainder in your own wallet. To send assets to another party, you must first obtain a Taproot Asset address from the intended recipient. Unlike traditional Bitcoin addresses, Taproot Asset addresses are specifically generated for particular assets and amounts, making them unique to each transaction. - -The transfer process involves coordination between sender and recipient, where the sender first communicates the genesis bootstrap info key and the intended transfer amount to the recipient. The recipient then uses this information to generate a specific Taproot Asset address for receiving the exact asset and amount being transferred. Once the sender receives this address, they can execute the transfer using the `assets send` command. After completing an asset transfer, you can verify the transaction's success by using the `assets list` command again, which will reflect the updated asset balances. - -For continued learning and more detailed information about Taproot Asset's capabilities, the comprehensive documentation available at [docs.lightning.engineering](https://docs.lightning.engineering/) provides extensive resources, tutorials, and technical specifications. As Taproot Asset continues to evolve and mature, staying connected with the official documentation and community resources will ensure you remain current with the latest developments and best practices in the Taproot Asset ecosystem. - -## Tap into the Universe -c9b7e4f3-5d8a-4c2e-9f6b-8a3d5e7c2b19 - -:::video id=939fd065-61ec-42e0-9f19-543d7bb4f3fd::: - -### Taproot Assets Version 0.2: Advanced Features and Implementation - -Taproot Assets version 0.2 represents a significant advancement in Bitcoin's asset issuance capabilities, building upon the foundational concepts introduced in earlier versions. This release introduces sophisticated features for asset management, transaction coordination, and proof validation that enable developers to create robust applications on the Bitcoin blockchain. The Lightning Labs implementation, known as Tapd (Taproot Assets daemon), serves as the reference implementation for this protocol while maintaining the commitment to privacy and decentralization. - -The version 0.2 release introduces sophisticated asset group functionality that enables more flexible minting strategies. Asset groups allow developers to create fungible assets across multiple minting rounds or tranches, providing greater control over asset supply management. When emission is enabled during the initial minting process, the resulting asset becomes part of an asset group that can accommodate future tranches, with each subsequent minting operation sharing the same group ID. Conversely, when emission is disabled (the default behavior), the minting process creates an asset with a permanently capped supply, ensuring that asset creators can make credible commitments about supply limitations. - -One of the powerful features of the Taproot Assets protocol is its ability to handle multiple asset types within a single Bitcoin transaction. This capability significantly improves efficiency by allowing users to transfer various assets simultaneously without requiring separate on-chain transactions for each asset type. The protocol achieves this through sophisticated commitment structures that embed multiple asset transfers within the same Bitcoin transaction outputs, reducing on-chain footprint while maintaining the security guarantees of the Bitcoin blockchain. - -### API Architecture and PSBT Coordination - -The Taproot Assets daemon provides comprehensive API access through multiple interfaces, enabling developers to integrate asset functionality into their applications using familiar tools and patterns. The API structure is organized into four primary services: the AssetWalletService manages wallet operations and asset holdings, the MintService handles all asset creation operations, the TaprootAssetService manages core protocol operations such as transfers and proof validation, and the UniverseService provides functionality for asset discovery, synchronization, and proof distribution. - -Each service within the API architecture is designed to work cohesively while maintaining clear separation of concerns. The API design follows RESTful principles for HTTP endpoints while providing the performance benefits of gRPC for applications requiring high-throughput operations. The comprehensive nature of these APIs enables developers to build complete Taproot Assets applications without requiring direct interaction with the underlying Bitcoin infrastructure. - -The Taproot Assets protocol makes sophisticated use of Partially Signed Bitcoin Transactions (PSBTs) to coordinate complex multi-party operations. The implementation extends this concept through two distinct PSBT types: virtual PSBTs and anchor PSBTs. Virtual PSBTs (vPSBTs) represent an innovative extension of the standard PSBT format, specifically designed to coordinate asset-level operations between Taproot Assets daemons. These virtual transactions use the familiar PSBT structure while adding custom fields that communicate asset-specific data such as Merkle tree updates, proof information, and asset commitment details. - -Once the asset-level coordination is complete through virtual PSBTs, the parties must create an actual Bitcoin transaction to anchor their asset changes on the blockchain. This process uses standard PSBTs, referred to as anchor PSBTs in the Taproot Assets context. The anchor PSBT coordinates the creation of the Bitcoin transaction that will contain the new asset commitments, ensuring that all parties can contribute their signatures and finalize the on-chain transaction. This dual-PSBT architecture offers significant advantages for application developers by allowing them to reuse existing Bitcoin transaction handling code while providing sophisticated coordination capabilities for complex asset transfers. - -### Universe Architecture and Proof Systems - -The Taproot Assets protocol relies heavily on cryptographic proofs to enable secure, private, and verifiable asset operations. Proofs contain comprehensive information about an asset's history, including its creation, all subsequent transfers, and the current ownership state. Each proof includes the necessary cryptographic evidence to validate the asset's authenticity and verify that all previous operations followed the protocol rules. This design enables users to independently verify asset legitimacy without requiring access to the complete blockchain history or trusted external services. - -The Tapd implementation provides comprehensive tools for working with proofs through various API endpoints. The query proof functionality allows applications to retrieve specific proofs from universe servers using asset identifiers or group keys. Proof import functionality allows applications to add new proofs to their local universe instances, facilitating the distribution of asset information across the network. The wallet API includes specialized endpoints for verifying asset ownership using proofs, involving checking cryptographic signatures, validating Merkle tree structures, and ensuring that all referenced Bitcoin transactions exist on the blockchain. - -The universe system represents a crucial infrastructure component that facilitates asset discovery and proof distribution within the Taproot Assets ecosystem. A universe can be conceptualized as serving multiple roles simultaneously: a virtual mempool for pending asset operations, an explorer for asset history, a repository for proof data, and a transaction library for completed operations. Operating a universe server is straightforward, as the functionality is built directly into the Taproot Assets daemon—any Tapd instance can serve as a universe by configuring it to listen on the appropriate RPC port and ensuring network accessibility. - -The federation concept extends the universe model to enable coordination between multiple universe servers. Each client can define its own federation, which represents a set of trusted universe servers from which it will accept asset information and proof data. Federation members periodically synchronize with each other, exchanging information about newly created assets and completed transfers. This federated approach provides redundancy, improves data availability, and enables users to choose their preferred sources of asset information while balancing decentralization with practical usability concerns. - -The REST API provides practical access to universe functionality through standard HTTP endpoints, with Python and JavaScript examples demonstrating how applications can query asset information, retrieve proof data, and interact with universe servers. The comprehensive nature of the API documentation and example implementations reduces the barrier to entry for developers interested in building Taproot Assets applications, providing them with the resources necessary to create sophisticated asset management applications while leveraging the security and privacy properties of the Bitcoin blockchain. - - -# Initial Installation and Configuration -f2d8c5e9-6b3a-4e7c-8d9f-1a5c3b7e9f28 - -## Install from Source -a8e9f3b2-7c5d-4f1e-b6a9-2d8c5e3f7a31 -:::video id=70e894f7-3759-48fc-9fcb-a3a1b33a3214::: - -### Installing TAPD: A Complete Setup Guide - -The Taproot Assets Protocol Daemon (TAPD) represents a significant advancement in Bitcoin's asset management capabilities, enabling users to mint, transfer, and manage assets on the Bitcoin blockchain through the Lightning Network. This comprehensive installation guide will walk you through the complete process of setting up TAPD on an Ubuntu system, from initial prerequisites to final configuration. TAPD operates as a daemon that works in conjunction with both Bitcoin Core and the Lightning Network Daemon (LND), creating a powerful stack for asset management. - -Before beginning the TAPD installation process, several critical prerequisites must be in place to ensure a successful setup. Your system must have Bitcoin Core (bitcoind) already installed and synchronized with the blockchain. For this installation, we'll be working on the Bitcoin testnet, which is the recommended approach for initial development and testing. The Lightning Network Daemon (LND) must be version 0.17 or greater to support TAPD version 0.3, as earlier versions lack the necessary features and compatibility for proper operation. - -Installing TAPD from source requires a properly configured Go development environment with version 1.21 or later installed, as earlier versions may cause compilation errors or compatibility issues. The installation process also requires appropriate system permissions and a non-root user account for security best practices. TAPD offers several installation approaches: source installation provides the most flexibility and ensures you're working with the latest code, while binary installations offer convenience and speed for production deployments. - -### Step-by-Step Installation and Configuration - -The installation process begins with obtaining the TAPD source code and preparing the build environment. Navigate to your user's home directory and clone the TAPD repository from the official Lightning Labs GitHub. After cloning, it's essential to checkout the specific version you want to install rather than using the development branch, which may contain unstable or experimental features. For this installation, we'll use version 0.3.0, which represents a stable release with full mainnet compatibility. - -The compilation process uses Go's built-in build system through the provided Makefile. The `make install` command handles all compilation steps, dependency resolution, and binary installation automatically. During compilation, the build system creates two primary binaries: `tapd` (the main daemon) and `tapcli` (the command-line interface). These binaries are installed in your Go binary directory, typically located at `$HOME/go/bin/`. - -Proper configuration is crucial for TAPD operation, as the daemon must communicate with both Bitcoin Core and LND while providing its own API endpoints. While TAPD can be started directly from the command line with all parameters specified as flags, creating a dedicated configuration file provides a more maintainable and error-resistant approach. The configuration file should be placed in the TAPD data directory, which must be created before first startup. Essential configuration parameters include network specification (testnet for development, mainnet for production), debug logging levels, LND connection details, and API endpoint definitions. - -Security configuration involves specifying the correct paths to LND's TLS certificate and macaroon files. These files provide the cryptographic credentials necessary for secure communication between TAPD and LND. The paths must be accurate and accessible to the user account running TAPD, as incorrect paths will prevent daemon startup. - -### System Integration and Verification - -Integrating TAPD as a system service ensures reliable operation, automatic startup, and proper dependency management. Creating a systemd service file enables automatic TAPD startup, proper dependency ordering, and integration with system logging and monitoring tools. The service file must specify the correct binary path, user account, and dependency relationships with other services. Most importantly, the service must be configured to start only after LND is fully operational, as TAPD depends on LND's API services. - -The systemd configuration should include appropriate restart policies to handle temporary failures and ensure service availability. Setting a reasonable startup delay after LND initialization helps prevent race conditions during system boot or service restart scenarios. Once the systemd service is configured and enabled, standard systemd commands provide complete service lifecycle management. Proper service integration also enables automatic startup during system boot, ensuring that your TAPD installation remains operational even after system restarts or power cycles. - -After completing the installation and configuration process, thorough verification ensures that all components are working correctly. The first verification step involves confirming that all required services are running correctly—your system should show Bitcoin Core, LND, and TAPD all in active states with no error conditions. Beyond basic service status, verification should include testing TAPD's API responsiveness and network connectivity. The TAPD CLI provides tools for basic functionality testing and can confirm that the daemon is properly connected to both the Bitcoin network and Lightning Network. - -Alternative approaches may be more suitable for specific use cases. Binary installations eliminate the need for development tools and reduce installation time significantly. Lightning Terminal (LitD) provides an integrated approach that combines all Lightning Labs services into a single package, simplifying deployment and management while providing a unified interface for all Lightning Network operations. - -The most frequent installation problems relate to Go version compatibility, incorrect file paths, or permission issues. Comprehensive documentation is available at docs.lightning.engineering, providing detailed information about configuration options, API usage, and troubleshooting procedures. For real-time assistance, the Lightning Labs Slack community provides direct access to developers and experienced users who can offer guidance and support. - -## Prototype with Polar -d5c7f8e3-9a2b-4e6c-8f1d-3b9e5a7c4d32 -:::video id=30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b::: - -### Setting Up TAPD with Polar Development Environment - -The TAP Root Assets Daemon (TAPD) Demo Series provides developers with comprehensive guidance for working with Taproot assets, covering everything from initial installation through asset minting, transferring, and burning operations. This chapter focuses specifically on utilizing Polar as a development environment for TAPD experimentation and testing. Polar represents a powerful solution for Bitcoin and Lightning Network development, offering one-click deployment of complete network environments for local application development and testing. - -Polar serves as a comprehensive development environment that supports Mac, Windows, and Linux operating systems. The application functions as a Docker-based solution, requiring Docker to be installed and properly configured on the development machine. The application operates by creating local simulations of Bitcoin and Lightning Network environments, utilizing the same software components that would run on testnet or mainnet deployments. This approach ensures that development work translates directly to production environments while providing the safety and convenience of local testing. - -Creating a functional TAPD development environment begins with establishing a basic Lightning Network topology. A typical setup requires at least two Lightning Network Daemon (LND) nodes, as TAPD specifically requires LND as its underlying Lightning implementation. The network topology also necessitates at least one Bitcoin Core backend node, which serves as the foundation for all blockchain operations. This backend provides the essential infrastructure for embedding Taproot asset data into the Bitcoin blockchain, maintaining the security and immutability characteristics that make Taproot assets viable. - -### Configuring Nodes and API Access - -Once the basic Lightning Network infrastructure is established, TAPD nodes can be integrated into the topology through Polar's intuitive drag-and-drop interface. Each LND node requires a corresponding TAPD node to handle Taproot asset operations. This pairing creates a complete environment where Lightning Network functionality coexists with Taproot asset capabilities, enabling comprehensive testing of asset-related operations within Lightning channels. The initial network startup process may require several minutes on first execution, as Docker downloads the necessary container images for all network components. - -Proper environment configuration begins with enabling auto-mining functionality, which eliminates the need for manual block generation during development and testing. This feature proves particularly valuable during asset minting operations, which require blockchain confirmations to complete successfully. Node funding represents another critical configuration step, as asset minting operations require on-chain Bitcoin transactions. Polar simplifies this process by providing built-in funding mechanisms that automatically generate the necessary Bitcoin balances for development purposes. - -Each node within the Polar environment provides comprehensive connection information, including details for both REST and gRPC API access. This information includes network addresses, port configurations, and authentication credentials necessary for external applications to interact with the nodes. The system automatically generates TLS certificates and macaroon files required for secure API communication. The connection information proves essential for developers building applications that interact with TAPD nodes programmatically, enabling secure and authenticated communication with all network components. - -### Asset Operations and Development Workflow - -TAPD provides comprehensive API access through both REST and gRPC interfaces, enabling developers to integrate Taproot asset functionality into applications using their preferred programming languages and frameworks. Initial exploration typically begins with basic asset listing operations, which query nodes for their current asset holdings. Newly created nodes naturally return empty asset lists, providing a clean starting point for experimentation. - -Asset minting represents one of the most fundamental TAPD operations, enabling the creation of new Taproot assets with specified quantities and characteristics. The minting process involves two distinct phases: batch creation and batch finalization. During batch creation, the system prepares all necessary data structures and cryptographic commitments required for asset creation, but does not yet commit this information to the blockchain. The batch finalization phase completes the minting process by embedding the prepared asset data into Bitcoin blockchain transactions. - -Following successful asset minting and blockchain confirmation, developers can verify their operations by querying node asset lists and examining detailed asset information. This verification process confirms that assets have been properly created and are available for subsequent operations such as transfers or burns. The detailed asset information includes all relevant metadata, ownership details, and transaction history associated with each asset. The verification process also demonstrates the integration between TAPD operations and the underlying Bitcoin blockchain, showing how Taproot asset data is embedded within Bitcoin transactions while maintaining the security characteristics of the base layer. - -Effective TAPD development using Polar follows a structured workflow that begins with network setup and progresses through increasingly complex operations. Troubleshooting and support resources play a crucial role in the development process, with the Polar project repository serving as a primary resource for resolving common issues and configuration challenges. The Lightning Labs community, accessible through various channels including Slack, provides additional support and collaboration opportunities for developers working with TAPD and related technologies. - -## Launch with Litd -b7f9a2c5-8e3d-4b7a-9c6f-5d2e8a3b1f43 - -:::video id=c488fe53-5110-4e43-8b9c-7773d9969078::: - -### Installing TAPD via Lightning Terminal from Source - -Lightning Terminal (LitD) represents a comprehensive solution for running multiple Lightning Labs services in an integrated environment. When installing TAPD through LitD, you gain access to not just the Taproot Assets daemon, but also LND, Loop, Pool, and Faraday all running together seamlessly. This integrated approach eliminates the complexity of managing separate installations and configurations for each service, making it an ideal choice for users who want a complete Lightning Network and Taproot Assets setup. - -Before beginning the installation process, several prerequisites must be satisfied to ensure a successful build from source. The system requires recent versions of Go, Node.js, and Yarn, as these are essential for compiling the various components that make up the LitD suite. The demonstration environment consists of an Ubuntu server running BitcoinD on the testnet, which provides a realistic testing environment that mirrors production setups while using testnet Bitcoin to avoid any risk to real funds. - -The installation process begins with cloning the Lightning Terminal repository from GitHub at `github.com/lightninglabs/lightning-terminal.git`. After cloning, it's important to check out the latest stable version rather than using the development branch, as this ensures you're working with tested, stable code. The compilation process utilizes the standard Go build system through the `make install` command, compiling not only the LitD daemon itself but also all the integrated services including LND, TAPD, Loop, Pool, and Faraday. - -### Configuration and Wallet Setup - -Proper configuration is crucial for LitD operation, beginning with creating a dedicated configuration directory `.lit` in the user's home directory. Within this directory, the `lit.conf` file contains all necessary configuration parameters for the integrated services. Key configuration elements include network selection (testnet or mainnet), backend Bitcoin node configuration, authentication settings, and service-specific parameters. The integrated mode setting is particularly important as it tells LitD to manage all services internally rather than connecting to external instances. - -The Bitcoin backend configuration represents one of the most critical aspects of the setup. When using BitcoinD as the backend, the configuration must specify the RPC connection details, including the host address, port, username, and password. Alternative backend configurations are possible, such as using Neutrino for a lighter-weight setup, which eliminates the need for a full Bitcoin node by using compact block filters but comes with trade-offs in terms of privacy and verification guarantees. - -Security considerations are paramount when configuring LitD, particularly regarding wallet management. The configuration includes provisions for automatic wallet unlocking, which involves creating a secure password file and enabling the auto-unlock feature. The first startup of LitD requires wallet creation through the `lncli create` command, during which you'll receive a [seed phrase](https://planb.academy/resources/glossary/seed) that serves as the ultimate backup for the wallet. This phrase can restore the wallet and all associated funds, making it essential to record it securely. - -### Service Integration and Verification - -Once LitD is running with a created wallet, verification of proper operation becomes essential. The `litcli status` command provides an overview of all running services and their current state, offering a quick health check for the entire system. Individual service testing involves using their respective CLI tools to perform basic operations—for LND, checking node information and sync status; for TAPD, querying for existing assets and verifying connectivity to universe servers. - -For production deployments, proper system integration through SystemD ensures reliable service management and automatic startup. Creating a SystemD service file for LitD involves defining the service dependencies, startup commands, and restart policies. The service should be configured to start after BitcoinD to ensure the Bitcoin backend is available when LitD initializes. Once the service file is created and enabled, SystemD manages the LitD process lifecycle, including automatic startup on system boot and restart on failure. - -The final verification step involves testing TAPD's connectivity to universe servers, which are essential for asset discovery and verification. Testing universe connectivity confirms that TAPD can properly communicate with external services and participate in the broader Taproot Assets ecosystem. This involves listing connected universes and potentially adding new ones to verify the networking and protocol implementation. The successful completion of these tests indicates that the installation is complete and ready for use in minting, transferring, and managing Taproot Assets. - -## Join a Universe Federation -e3d8b6f4-7c9a-4e2b-8f5c-9a1d3e6b7c54 -:::video id=42e7cc5c-18cf-47b0-9d42-879f14733cd5::: - -### Dicovering Universe Concepts - -In the Taproot Assets ecosystem, a universe serves as a fundamental data storage mechanism that enables nodes to share and synchronize asset information across the network. A universe functions like a library storing books with taproot asset data and proofs, operates similarly to a block explorer with searchable records, or resembles a GitHub repository hosting distributed data. - -When you initialize a TAPD (Taproot Assets Daemon) node, it automatically includes its own universe data store. The true power emerges when nodes connect to share data with other universes across the network. Adding another TAPD node's universe and establishing data sharing relationships is called "adding a universe to your federation" - your node's collection of trusted universe connections for accessing and synchronizing asset data from multiple sources. - -### Managing Universe Federations via CLI - -The command-line interface provides comprehensive federation management tools. The `tapcli universe federation list` command shows how many universes your node connects with, typically displaying at least one default universe that connects automatically upon startup. - -Adding universes requires specifying the target universe's location using `tapcli universe federation add` followed by the network address. This user-controlled process allows strategic connections to universes serving specific needs. For example, connecting to a trading partner's universe enables access to relevant asset data and proofs for successful transactions. - -Periodic synchronization via `tapcli universe sync` ensures your local universe contains the most recent asset data from connected universes - particularly important in active trading scenarios. The `tapcli universe roots` command reveals all assets your universe has discovered through federation connections, providing a comprehensive view of the accessible taproot asset ecosystem. Federation management remains flexible with the ability to remove universes using `tapcli universe federation delete`. - -### API-Based Universe Management - -Working with universes through the API requires proper TAPD node REST interface configuration and security practices. The REST API enables programmatic access to all universe management functions for custom applications and automated workflows. Configuration involves setting the `restlisten` parameter to specify which network interfaces accept API connections. - -Security considerations are paramount, requiring careful implementation of authentication mechanisms using macaroon files for granular permission control. The TLS certificate system ensures encrypted communication, protecting sensitive data from network interception. - -Python scripts for universe management typically import the requests module, configure connection parameters including REST host address, authentication macaroons, and TLS certificates. Adding universes involves POST requests to the `universe/federation` endpoint with properly formatted target universe location data. - -The API provides rich statistics through endpoints like `universe/stats`, returning comprehensive data about asset awareness and federation status. These metrics help monitor your node's network integration, identify synchronization issues, reveal asset diversity growth, and provide insights into activity patterns influencing trading decisions. - -### Practical Applications and Best Practices - -Universe management serves various purposes from simple asset discovery to complex multi-party trading arrangements. Asset exchanges represent common use cases where parties need access to each other's asset data for verification, validation, and successful transfers. Adding relevant universes ensures access to necessary transaction information. - -Best practices include maintaining a curated federation serving specific needs rather than connecting to every available universe, which could overwhelm your node and create security exposure. Regular synchronization schedules ensure data currency without excessive network overhead. Periodic federation review allows removal of inactive or irrelevant connections. - -The combination of CLI and API access provides operational flexibility - CLI commands for manual administration and testing, API integration for automated workflows and applications. Understanding both approaches ensures choosing the most appropriate method for each universe management task while maintaining consistent operational practices across your taproot asset infrastructure. - -# First Mints and Transactions -c4d0776e-870b-11f0-86c9-8fee09142fba - -## Mint from the CLI -f5b9c3e7-8d2a-4f7e-9b6c-3a8d5e2c1f76 - -:::video id=3bc078b4-183d-4970-b63e-66862a452566::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through [proof-of-work](https://planb.academy/resources/glossary/proof-of-work) consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Mint from the API -a9d7e5f8-3c6b-4e9a-8f2d-6b1c3a9e5d87 - -:::video id=89819d63-3011-4ac6-a1f7-66babd2134b8::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - -### Best Practices for MINT through API - -Asset transfers require on-chain confirmation before receiving nodes update their balance information. This confirmation process ensures that transfers are irreversibly committed to the blockchain before being reflected in node balances. The receiving node monitors the blockchain for transaction confirmation and validates the associated proof data before updating its internal asset records. The confirmation process may take several minutes depending on Bitcoin network conditions and the number of confirmations required. - -After sufficient on-chain confirmations, the receiving node updates its asset balances to reflect the completed transfer. The asset listing functionality can then be used to verify that the transfer completed successfully and that the receiving node now holds the expected asset quantities. This verification step is essential for confirming end-to-end transfer functionality and diagnosing any potential issues in the transfer process. - -When implementing API-based asset transfers in production applications, error handling should account for network failures, authentication issues, and blockchain-related delays. Security considerations include proper macaroon and certificate management, secure communication channels, and appropriate access controls for API endpoints. Production deployments should implement monitoring and logging to track transfer operations and diagnose issues. The API-based approach enables sophisticated asset management workflows, including automated transfers, batch operations, and integration with existing financial systems. - -## Send from the CLI -d2c8f6b3-7e5a-4b9d-8c3f-9a6e2d5b1c98 - -:::video id=88cdc6ce-22f6-4ddd-90a3-da345a85eef1::: - -### Transferring Taproot Assets via Command Line Interface - -This guide demonstrates transferring Taproot assets between nodes using the CLI, building on our previous minting operations. We'll use a two-node setup—Alice and Bob—to illustrate the complete transfer workflow within the Taproot Assets Protocol Daemon (TAPD) ecosystem. - -Unlike traditional centralized systems that update databases, Taproot asset transfers leverage Bitcoin's blockchain infrastructure while maintaining efficiency and privacy benefits. This ensures cryptographically secure, verifiable transfers while preserving Bitcoin's decentralized nature. - -### Node Configuration and Universe Federation - -Our demonstration uses two distinct nodes: Alice (primary node on Ubuntu) and Bob (older testnet configuration). Both maintain full TAPD functionality and participate in a universe federation—a critical requirement for successful transfers. - -The universe system enables nodes to share asset metadata and maintain synchronized information about available assets. Without this shared understanding, receiving nodes would lack the necessary information to properly request and validate incoming transfers. This federation approach eliminates manual coordination of asset metadata between parties. Instead of Alice separately communicating asset details to Bob, the universe system ensures Bob's node automatically maintains awareness of available assets, significantly streamlining the transfer process while maintaining security standards. - -### Asset Transfer Workflow - -Before initiating transfers, we verify Alice's current holdings: 200 CLI demo tokens and a reduced quantity of API demo tokens (having previously transferred 10 to another party). This existing transfer history demonstrates accurate balance tracking across multiple transactions. - -The verification process examines both quantity and specific batch information for each asset type. Each asset carries unique identifying information, including an asset ID that serves as the primary reference for all transfer operations—functioning like a unique identifier in traditional databases but within the Taproot protocol's cryptographic framework. - -The transfer begins with Bob generating a specialized address containing all information Alice needs. Bob uses the command: `tapcli address new --asset_id [ASSET_ID] --amt [AMOUNT]`. The asset ID specifies which asset Bob wishes to receive, while the amount indicates the desired quantity. In our demonstration, Bob requests 10 API demo tokens. - -Upon execution, Bob's node produces an encoded TAPD address—a lengthy string containing destination information, cryptographic proofs, and validation data required for secure transfer. The transmission of this address from Bob to Alice occurs outside the TAPD protocol, typically at the application layer. This design maintains flexibility in communication while ensuring standardized, secure cryptographic operations. - -With Bob's encoded address, Alice executes: `tapcli assets send --addr [ENCODED_ADDRESS]`. This command instructs Alice's node to construct and broadcast the on-chain transaction transferring the specified assets to Bob. Despite complex behind-the-scenes operations—Bitcoin transaction construction, cryptographic proof generation, and network coordination—the CLI interface presents a simple command structure. - -Upon successful execution, Alice's node provides comprehensive transfer information, including cryptographic proofs transmitted to Bob's node. These proofs serve as verifiable evidence, allowing Bob to independently confirm legitimate asset transfer. The system generates an on-chain transaction ID verifiable through standard Bitcoin block explorers. - -This proof generation represents a critical security feature. Rather than requiring trust between parties, the system generates mathematical proofs independently verifiable by any participant, maintaining Bitcoin's trustless nature while enabling sophisticated asset transfers. - -### Transfer Verification and Technical Considerations - -The `tapcli assets transfers` command provides comprehensive data about all node transfers, including status, proof data, and transaction details—invaluable for troubleshooting or monitoring node activity. - -Transfer verification requires patience as the system awaits on-chain confirmation before updating balances. This ensures proper recording on the Bitcoin blockchain with sufficient security through proof-of-work consensus. The process typically requires one or more blocks after transaction inclusion. During this period, transfers exist in pending state, with final confirmation occurring after required blocks are added. - -Following successful confirmation, both nodes update their balances automatically. Alice's API demo tokens reduce from 100 to 90, while Bob receives 10 new tokens. This automatic reconciliation occurs without manual intervention, demonstrating the system's ability to maintain accurate state across distributed nodes. - -Successful transfers depend heavily on proper universe federation configuration and synchronization. Nodes must maintain current asset information to facilitate smooth operations. The universe system operates continuously in the background, updating asset information and maintaining synchronization with federated nodes. This ongoing process requires minimal user intervention but represents a critical component of the overall architecture. - -Users should expect brief delays between transfer execution and balance updates as the system awaits blockchain confirmations. This fundamental security feature prevents various attack vectors while maintaining compatibility with Bitcoin's security model. Ensure nodes maintain proper connectivity to relevant universe federations for seamless operations. - -The transfer system exemplifies sophisticated engineering underlying the Taproot Assets Protocol, combining Bitcoin's security with efficient asset management. By abstracting complex cryptographic operations behind simple CLI commands, the system makes advanced functionality accessible while maintaining fundamental security and decentralization principles. - -## Send from the API -b6f3d9a8-5c2e-4d7b-9f8a-1e3c6b8a7d19 - -:::video id=db1c8655-eb0b-49a1-83e8-dc0b16a35582::: - -### Introduction to API-Based Asset Transfers - -The Taproot Assets Daemon (TAPD) provides multiple interfaces for interacting with taproot assets, including command-line tools and programmatic APIs. While the CLI offers direct control for manual operations, the REST API enables developers to integrate asset management capabilities into applications and automated systems. This chapter demonstrates how to transfer taproot assets between nodes using TAPD's REST API through Python scripts, building upon the foundational concepts of minting and CLI-based transfers covered in previous sections. - -The REST API approach offers several advantages for production environments and application development. It allows for seamless integration with existing web services, enables automated asset management workflows, and provides a standardized interface that can be consumed by various programming languages and platforms. Understanding both the technical implementation and the underlying asset transfer mechanics is essential for developers building applications on the taproot assets protocol. - -### Prerequisites and Configuration - -The comprehensive API documentation for TAPD is available at lightning.engineering/api-docs/api/taproot-assets, serving as the definitive reference for all available endpoints and functionality. This documentation provides detailed information for both gRPC and REST implementations, with practical examples in JavaScript and Python for each API call. The documentation structure mirrors the functionality available through the CLI, making it easier for developers to transition between different interaction methods. - -Before initiating API-based asset transfers, several prerequisites must be satisfied to ensure successful communication between nodes. The transferring nodes must have proper network connectivity with appropriate firewall configurations to allow REST API communication on the designated ports. Each TAPD instance must be configured to accept incoming connections on its REST API port, which requires specific configuration file modifications. - -Authentication and authorization are handled through macaroon files and TLS certificates, which must be properly distributed to client applications. The admin macaroon provides full access to node functionality and should be securely stored and transmitted. TLS certificates ensure encrypted communication between clients and TAPD nodes, maintaining security for sensitive asset operations. - -A critical prerequisite for asset transfers is ensuring that the receiving node has complete information about the assets being transferred. When Alice mints assets on her TAPD node, her node automatically possesses all necessary asset information, including genesis transaction data and proof information. However, Bob's node must acquire this information through universe synchronization before it can participate in asset transfers. - -Universe federation enables nodes to share asset information automatically, ensuring that participating nodes maintain synchronized views of available assets. In the demonstration setup, Alice and Bob's universes are configured in each other's federation, allowing automatic information sharing. Alternative configurations might involve both nodes connecting to a shared public universe server, but the fundamental requirement remains that receiving nodes must have complete asset information before transfers can occur. - -### API Operations and Transfer Workflow - -The Python scripts demonstrate a straightforward approach to connecting with remote TAPD nodes using REST API calls. Connection configuration requires specifying the target node's IP address and REST API port, along with proper authentication credentials. The demonstration setup involves running Python scripts locally while connecting to remote Ubuntu servers hosting the TAPD nodes, illustrating a common deployment pattern for distributed asset management systems. - -The asset listing functionality provides a foundation for understanding API interaction patterns and serves as a diagnostic tool for verifying node state. The assets endpoint (`/taproot-assets/assets`) accepts GET requests and returns comprehensive information about all assets held by the querying node. This endpoint requires no additional parameters beyond authentication, making it ideal for initial API exploration and system status verification. - -Address generation represents a crucial step in the asset transfer process, where the receiving node creates a specialized address containing all information necessary for the sender to construct a valid transfer transaction. The addresses endpoint (`/addresses`) accepts POST requests with required parameters including the asset ID and the desired amount to receive. The generated address contains encoded information that enables the sending node to construct appropriate on-chain transactions for asset transfers. - -The asset transfer execution involves the sending node constructing and broadcasting an on-chain Bitcoin transaction that moves the specified taproot assets to the receiving address. This process is initiated through the send endpoint (`/send`), which accepts the previously generated address as its primary parameter. The sending node validates the address, constructs the appropriate transaction, and handles the on-chain broadcast automatically. - - -## Burn from the CLI -e8a9b5c2-4f7d-4e3a-8b6c-7d2f9e1a3b21 -:::video id=a9a437a4-1664-4786-a4a8-6e78082abe59::: - -### Asset Burning via CLI - -Asset burning represents the final operation in the complete lifecycle of Taproot Assets Protocol Daemon (TAPD) management. This process allows users to permanently destroy digital assets, removing them from circulation in an irreversible on-chain transaction. The burning functionality serves various purposes, including reducing asset supply, removing unwanted tokens, or fulfilling specific protocol requirements that necessitate asset destruction. - -The CLI-based approach to burning assets provides a straightforward, command-line interface for this operation, making it one of the most direct methods available in the TAPD toolkit. Unlike other asset operations that may require multiple steps or complex configurations, burning assets can be accomplished with a single command execution, though it includes important safety mechanisms to prevent accidental destruction of valuable assets. - -### Prerequisites and Asset Inventory - -Before initiating any burning operations, users must have a properly configured TAPD node with existing assets available for destruction. The demonstration environment utilizes a TAPD demo node that has previously completed the full asset lifecycle, including installation, minting, and transfer operations. This node contains multiple rounds of different asset types, providing a realistic testing environment for burning operations. - -The first step in any burning operation involves examining the current asset inventory to identify which assets are available for destruction. The asset listing command provides a comprehensive overview of all assets currently held on the node, displaying crucial information including asset IDs, quantities, and asset types. This inventory check ensures that users have accurate information about their holdings before proceeding with any destructive operations. - -Asset selection requires careful consideration of both the asset type and quantity to be destroyed. The selection process involves identifying the specific asset ID of the target asset and determining the appropriate amount to burn. In typical scenarios, users might choose to burn a portion of their holdings rather than the entire balance, allowing for partial destruction while maintaining some quantity for future use. The asset ID serves as the critical identifier that ensures the burning operation targets the correct asset—this alphanumeric string uniquely identifies each asset batch and must be copied precisely to avoid errors. - -### Executing the Burn Command - -The asset burning command follows a straightforward syntax pattern that requires only two essential parameters: the asset ID and the quantity to burn. The complete command syntax follows the pattern: `tapcli assets burn [asset-id] [amount]`. This structure ensures that users provide both the specific asset identifier and the exact quantity they wish to destroy. The command's simplicity reflects the straightforward nature of the burning operation, though the underlying blockchain transaction involves complex cryptographic processes to ensure permanent asset destruction. - -The TAPD system incorporates a critical safety feature that prevents accidental asset destruction through an interactive confirmation prompt. When users execute a burn command, the system presents a confirmation dialog that explicitly warns about the permanent nature of the operation and requires explicit user consent before proceeding. This safety mechanism serves as the final checkpoint to prevent costly mistakes that could result in unintended asset loss. - -For users operating in automated environments or running scripted operations, the confirmation prompt can present operational challenges. The TAPD CLI provides a flag option that allows users to bypass the interactive confirmation, enabling seamless integration into automated workflows. However, this capability comes with significant responsibility, as it removes the primary safety mechanism designed to prevent accidental asset destruction. The bypass flag should only be used in carefully controlled environments where the burning operation is part of a well-tested automated process. - -### Transaction Processing and Verification - -Asset burning operations result in on-chain Bitcoin transactions that permanently record the destruction of the specified assets. These transactions follow standard Bitcoin network protocols while incorporating the specific Taproot Assets Protocol mechanisms that handle the asset destruction logic. The on-chain nature of these transactions ensures that the burning operation is permanently recorded and cannot be reversed or undone. - -Following the execution of a burn command, the system requires on-chain confirmation before updating local balance information. This confirmation process follows standard Bitcoin network protocols, typically requiring one or more block confirmations before the transaction is considered final. During this confirmation period, the local asset balance may not immediately reflect the burned assets, as the system waits for network validation. Users should expect a brief delay between command execution and balance updates, with the exact timing dependent on current network conditions and confirmation requirements. - -After receiving on-chain confirmation, users can verify the success of their burning operation by checking their updated asset balance. The verification process involves re-running the asset listing command to display current holdings and confirming that the burned quantity has been properly deducted from the total balance. In the demonstration example, burning ten units from a balance of ninety results in a new balance of eighty units, clearly showing the successful completion of the operation. - -Once confirmed on the blockchain, burned assets cannot be recovered or restored through any means. The burning process represents a permanent destruction of digital value, making the verification step crucial for ensuring that the operation achieved its intended purpose. The finality of burning operations underscores the importance of careful planning and verification before executing these commands. Users should always double-check their asset IDs, quantities, and intentions before confirming burn operations, as the permanent nature of these transactions makes them powerful tools for supply management but requires responsible use to avoid unintended consequences. - -## Burn from the API -c7d5e8f9-3b6a-4e2c-9f7d-8a1b5c3e6d32 - -:::video id=03e4464a-7ce8-4fb1-889c-83f8a52ac315::: - -### Asset Burning via REST API - -This chapter demonstrates how to burn Taproot assets using the TAPD (Taproot Assets Daemon) API, completing the fundamental asset lifecycle operations of install, mint, transfer, and burn. Asset burning permanently destroys digital assets, making it essential to understand both the technical implementation and safety considerations involved in this irreversible process. - -Unlike transfers or minting operations, burning assets permanently removes them from circulation, requiring careful consideration and appropriate safety measures. The burning operation represents the final stage in our comprehensive exploration of Taproot asset management, where precision and caution are paramount given the irreversible nature of asset destruction. - -The complete API documentation for Taproot assets is available at lightning.engineering/api-docs/api/taproot-assets, providing comprehensive information on all available API calls. The documentation includes both gRPC and REST API options, with extensive examples in JavaScript and Python. For practical implementation, the REST API using Python scripts offers an accessible approach to asset burning operations, with most examples directly adaptable from the provided documentation. - -### Node Connection and Pre-Burn Setup - -Establishing proper connection to your Taproot assets node requires several key components for secure communication. The connection setup involves identifying the target node's internet location and port configuration, ensuring the designated port is open and ready for API communication. In this demonstration, we connect to a node designated as the "Bob node," which requires specific network configuration and authentication credentials. - -Local machine setup requires copies of both the admin macaroon and TLS certificate to enable authenticated communication with the remote node. These security credentials ensure that only authorized users can perform sensitive operations like asset burning—the macaroon provides authentication tokens while the TLS certificate enables encrypted communication between the local script and the remote node. - -Before executing any burn operations, it's essential to verify the current asset inventory using the list assets endpoint. The list operation requires a simple GET request to the assets endpoint without additional parameters. This preliminary step ensures accurate information about available assets before proceeding with irreversible burn operations. The list assets response provides comprehensive information about each asset, including asset IDs, quantities, and detailed metadata. In our demonstration, the initial inventory shows 10 API demo books, providing a clear baseline for measuring the burn operation's effects. - -### Implementing the Burn Operation - -The asset burning process utilizes the taproot-assets/burn endpoint through a POST request requiring specific parameters. The burn operation demands the asset ID of the target assets (obtained from the previous list operation) along with the quantity to be destroyed. These parameters ensure precise control over which assets are burned and in what quantities. - -A critical safety feature requires explicit confirmation that you intend to destroy the specified assets. This confirmation parameter acts as a safeguard against accidental asset destruction, requiring developers to consciously acknowledge the operation's irreversible nature. The burn request must include this confirmation flag to proceed, preventing inadvertent execution of destructive operations. Without this confirmation, the API will reject the burn request, providing an additional layer of protection. - -The burn operation returns extensive information about the completed transaction, including confirmation of the burned quantity, transaction details, and metadata valuable for record-keeping and audit purposes. This comprehensive response ensures complete visibility into the burn operation's execution and results, maintaining consistency with other TAPD API operations in how information is presented and organized. - -### On-Chain Confirmation and Verification - -Asset burning operations require on-chain confirmation before the new balance reflects in subsequent queries. This blockchain confirmation requirement means immediate re-querying may still show pre-burn quantities until the transaction confirms on the blockchain. Understanding this timing consideration is crucial for applications needing to coordinate multiple operations or provide real-time balance updates. - -The confirmation process follows standard blockchain timing patterns, with exact duration depending on network conditions and confirmation requirements. During this waiting period, the burn transaction exists in a pending state—broadcast to the network but not yet incorporated into a confirmed block. This temporary delay is normal for blockchain operations and should be accounted for in application logic. - -After receiving on-chain confirmation, running the list assets operation again confirms successful burn completion. In our demonstration, the post-burn inventory shows 5 API demo books remaining, confirming exactly 5 assets were successfully burned as requested. This verification step provides definitive proof of correct execution and permanent asset quantity reduction. - -The verification process serves multiple purposes: providing a clear audit trail, enabling detection of unexpected results, and offering confidence in API functionality. Regular verification of operation results represents a best practice for maintaining accurate asset management records. - - - -# Diving deeper into Taproot Assets -863d9c88-870c-11f0-a2de-430d32152c27 - -## Update Tapd -a5b8f9c3-6d7e-4a2b-8c9f-2e3d7b1a5f54 -:::video id=df88fe13-4a2f-4251-82db-89ce07131947::: - -### Introduction to TAPD Updates - -Maintaining an up-to-date TAPD (Taproot Assets Daemon) node is essential for accessing the latest features, security improvements, and bug fixes. The update process varies depending on how you initially installed your TAPD node, and understanding these different approaches ensures you can maintain your node effectively while preserving your valuable data and configurations. - -This chapter covers three primary update methods corresponding to the three installation approaches demonstrated throughout this series: Polar for simplified development environments, pre-compiled binaries for standard deployments, and source code builds for maximum customization. Each method requires specific steps and considerations to ensure a smooth update process. - -### Updating Polar Installations - -When you've used Polar to set up your TAPD environment, updating involves both the Polar application itself and the node versions it manages. Polar provides a user-friendly interface for managing Lightning Network development environments, but this convenience comes with specific update procedures that differ from manual installations. - -The update process typically requires attention to two components: the Polar application and the underlying node software. Users should be prepared for the possibility that updating Polar may require recreating existing networks, as newer versions sometimes introduce changes incompatible with previous network configurations. - -To update a Polar-based TAPD installation, begin by opening the Polar application and checking for new node versions through the built-in update mechanism. However, if significant updates are available, you may need to download a completely new version of Polar from lightningpolar.com, where the latest versions are available for Linux, Mac, and Windows platforms. When downloading a new version, be aware that you may need to recreate previously established networks. Plan accordingly by documenting your current network setup before proceeding with major updates. - -### Updating Binary Installations - -Before updating binary installations, it's crucial to understand your current system configuration and identify where your binaries are located. Most standard binary installations place executable files in `/usr/local/bin`, while data directories are typically located in your home directory under names like `.bitcoin`, `.lnd`, and `.tapd`. - -The update process requires careful attention to system services and data preservation. If you've configured your TAPD node to run as a systemd service, you'll need to properly stop these services before replacing the binaries. This ensures no processes are accessing the files you're about to replace and prevents potential corruption or conflicts. - -To update binary installations, begin by stopping all related services using systemd or your preferred service management system. Once services are properly stopped, navigate to your binary directory (typically `/usr/local/bin`) and remove the old binary files. This step is crucial because simply overwriting files can sometimes lead to permission issues or incomplete updates. - -After removing old binaries, install new versions using the same process as initial installation: downloading the latest release, verifying checksums and signatures, and copying binaries to the appropriate directory with correct permissions. Once new binaries are in place, restart your services and perform verification checks to ensure everything functions correctly. - -A critical aspect of updating binary installations is preserving your data directories. These directories contain blockchain data, channel information, wallet files, and other crucial operational data. Under no circumstances should you modify or delete these directories during an update unless you specifically intend to start fresh. The separation between executable binaries and data directories is fundamental to proper node management—while you replace program files during updates, data directories remain untouched, ensuring continuity of your node's operational history. - -### Updating Source Installations - -Updating TAPD installations built from source requires attention to your development environment, particularly your Go programming language version. Before beginning any source update, verify that your Go installation meets requirements for the latest TAPD version. Version compatibility issues can cause compilation failures or runtime problems difficult to diagnose after the fact. - -Before updating, properly shut down your TAPD service to prevent data corruption. The recommended approach involves using both the TAPD CLI stop command and your system service manager. First, execute `tapcli stop` to gracefully shut down the daemon, allowing it to complete pending operations and properly close database connections. Then stop the systemd service to ensure the process is completely terminated. Verify the service has stopped before proceeding. - -Navigate to your TAPD source directory and use Git to pull the latest changes from the repository. The command `git pull` retrieves recent commits and updates your local repository. After pulling changes, choose to update to the latest stable release or select a specific version, including release candidates for testing purposes. For production nodes, stable releases are recommended, while development or testing nodes can safely use release candidates. Use `git checkout` followed by the desired version tag to switch versions. - -Once you've selected the appropriate version, compile and install using `make install`. This process compiles Go source code and installs resulting binaries to your system's binary directory. During compilation, pay attention to error messages or warnings indicating compatibility issues or missing dependencies. Successful compilation should complete without errors and result in updated binary files with current timestamps. - -After compilation, perform thorough verification to ensure success. Check the version using `tapcli version` to confirm you're running the expected version. Restart your TAPD service using systemd, then verify it starts correctly and achieves an active, running state. Use system monitoring tools to confirm TAPD is listening on expected ports and responding to commands. Finally, perform basic functionality tests to ensure the updated version operates correctly with existing data. - -### Best Practices and Considerations - -When updating TAPD, carefully consider which version to install based on your node's role. Production nodes should use stable releases thoroughly tested for reliability. Development and testing nodes can benefit from release candidates or development branches to help identify issues and test new features. Keep track of release notes to understand changes included in each update, as some may include breaking changes or require specific migration procedures. - -Before performing any update, ensure current backups of critical data, including wallet files, channel databases, and configuration files. While updates typically preserve existing data, backups provide insurance against unexpected issues. Document your current configuration and custom settings before updating, as some updates might reset configuration files or require reconfiguration of specific features. - -The update process for TAPD nodes varies significantly depending on installation method, but following proper procedures ensures smooth transitions to newer versions while preserving valuable node data and configurations. Regular updates keep your node secure, performant, and compatible with the evolving Lightning Network ecosystem. - -## Building a Node from Scratch -992d8650-87f2-11f0-aace-9be7f0fb0b83 - -:::video id=9b884ff3-fca1-4488-bdd9-bb1d27ed5af4::: - -### Introduction to Lightning Terminal Daemon (LITD) - -Lightning Terminal Daemon, commonly referred to as LITD, represents a comprehensive solution for running Lightning Network infrastructure. This powerful tool bundles multiple essential components including LND (Lightning Network Daemon), Loop, Pool, Faraday, and Taproot Assets into a single, cohesive package. When setting up a LITD node, users gain access to LND along with an extensive suite of helpful tools that enhance the Lightning Network experience. - -The approach demonstrated in this chapter draws inspiration from established methodologies, particularly Alex Bosworth's Run LND repository, which provides detailed instructions for specific configurations such as running full archival nodes with external storage for blockchain data. This chapter focuses specifically on the streamlined setup process for LITD nodes using automated scripts and configuration files. - -The Run LITD repository serves as a collection of notes and helper scripts designed to facilitate quick and detailed LITD node setup. The repository includes configuration files and systemd service files that enable professional-grade node deployment. For users requiring granular control, comprehensive checklists outline every step necessary for manual setup, while automated bash scripts enable rapid node deployment with minimal manual intervention. - -Before proceeding with any automated setup process, users must understand the intended use case and limitations. The repository and associated scripts are specifically designed for developers who need to quickly spin up testing environments. While the underlying processes have been tested in production environments, the specific automated scripts should not be blindly trusted for production deployments without thorough review and testing. Production deployments require careful consideration of security implications, proper backup procedures, and thorough understanding of all configuration parameters. - -### Three-Stage Setup Process - -The LITD node setup process consists of three distinct stages, each handled by separate scripts that build upon the previous stage's configuration. This modular approach allows for troubleshooting individual components and provides flexibility in deployment scenarios. - -The initial stage focuses on basic server security and user configuration. This script creates a new user account with sudo privileges, disables root login and password authentication, and configures SSH key-based authentication. These security measures represent fundamental best practices for any server deployment and create a secure foundation for the Lightning Network node. The server preparation script requires root access for initial execution, as it modifies system-level security settings and user configurations. - -The second stage installs and configures Bitcoin Core, which serves as the blockchain backend for the Lightning Network node. The repository provides two approaches for Bitcoin daemon installation: compilation from source code and binary download with signature verification. Both methods ensure security through cryptographic verification. The source compilation approach provides maximum transparency and allows for custom compilation flags, while the binary download method offers faster deployment with equivalent security through signature verification. - -The final stage handles LITD installation, configuration file generation, and systemd service setup. This stage also provides options for source compilation or binary installation, with source compilation offering greater transparency and understanding of the installation process. The script generates appropriate configuration files that integrate with the previously installed Bitcoin daemon and establishes the necessary service files for automatic startup and management. - -### Practical Implementation Walkthrough - -The implementation process begins with a fresh Ubuntu server installation and proceeds through each setup stage systematically. Initial server access requires root login, which the first script will disable as part of the security hardening process. - -After gaining initial server access, the first step involves cloning the Run LITD repository and making the setup scripts executable. The server preparation script requires careful attention to SSH key configuration, as it will disable password authentication. Users must ensure they have properly configured SSH keys before proceeding. The script prompts for a sudo password for the new user account and requests SSH public keys for authentication. Multiple keys can be added by placing each key on a separate line, accommodating teams or users with multiple access devices. - -The Bitcoin daemon installation script handles dependency installation, binary download, signature verification, and initial configuration. The script generates a secure RPC connection string that enables communication between Bitcoin Core and LITD. This connection string must be carefully preserved, as it will be required during the LITD configuration phase. The script also prompts for network selection, allowing users to choose between mainnet, testnet, and signet. For development and testing purposes, signet provides an ideal environment that closely mimics mainnet behavior while using test coins without real value. - -The LITD installation process begins with dependency installation, including Go programming language, Node.js, and Yarn package manager. These dependencies enable compilation from source code and provide the runtime environment for LITD's web interface components. After dependency installation, users should log out and reconnect to ensure proper environment variable configuration. The second LITD script handles the actual compilation and installation process, which typically requires five to ten minutes depending on server specifications. - -### Configuration and Initial Startup - -After successful installation, LITD requires initial configuration and wallet creation before it can operate normally. This process involves starting LITD manually, creating a wallet, and then configuring automatic startup through systemd services. - -The initial LITD startup requires manual intervention to create and unlock the wallet. Users start LITD in one terminal session, which will pause waiting for wallet creation. In a separate terminal session, users execute wallet creation commands that establish the Lightning Network wallet and generate the seed phrase for backup. The wallet creation proces - -## Running a Taproot Assets Price Oracle -b3f7d9a5-8c2e-4b6d-9a7f-5e1c3d8b6a76 -:::video id=1694f29f-e009-4f0d-99d7-5cedb540c81a::: - -### Setting Up Price Oracles for Edge Networks - -Edge nodes serve as crucial intermediaries in the Taproot Assets ecosystem, facilitating seamless transactions between different asset types on the Lightning Network. To understand their function, consider a practical scenario where an edge node maintains both a stable coin channel with Alice and a regular Bitcoin channel with Bob. When Bob generates a Lightning invoice and sends it to Alice, she may prefer to pay using her stable coin holdings rather than Bitcoin directly. - -In this situation, Alice approaches the edge node with a specific request: she wants to send stable coins to the edge node, which will then forward the equivalent value in Bitcoin to Bob via the Lightning Network. The critical question becomes determining the exact exchange rate—how many stable coins must Alice send to ensure Bob receives the correct Bitcoin amount? This is where the price oracle becomes essential, serving as the authoritative source for real-time pricing information that enables accurate conversions between different asset types. - -The entire process operates through the Request for Quote (RFQ) system. Alice initiates an RFQ to the edge node, which consults its price oracle to calculate the current exchange rate based on Bitcoin's market price and the specific asset's valuation. The edge node then provides Alice with a precise quote, which she can either accept or reject. This mechanism ensures transparent, market-based pricing for cross-asset transactions while maintaining the Lightning Network's speed and efficiency. - -Price oracles function as sophisticated calculation engines that determine fair exchange rates between different assets in real-time. The demonstration price oracle queries external APIs to obtain current Bitcoin pricing information, maintains a registry of supported assets including their decimal precision and group key associations, and performs the mathematical calculations necessary to provide accurate conversion quotes. The oracle's decision-making process involves multiple considerations beyond simple price lookup, accounting for decimal display characteristics, applying appropriate scaling factors, and potentially differentiating between buy and sell operations. - -### Technical Implementation and Configuration - -The price oracle implementation begins with essential imports and configuration settings that establish its operational parameters. The code structure includes provisions for making the oracle publicly accessible, allowing multiple nodes across the network to utilize its services rather than requiring each node to maintain its own private oracle. This public accessibility enhances network efficiency and reduces redundant infrastructure requirements. - -Asset support configuration represents one of the most critical aspects of the oracle implementation. The system requires explicit declaration of which assets the oracle will support, preventing unauthorized or unknown assets from being processed. This is accomplished through asset ID specification for individual assets or group key designation for fungible asset families. Group keys prove particularly valuable for stable coin implementations, where multiple minting rounds create different asset IDs that should be treated as equivalent and interchangeable. - -Decimal display configuration addresses the practical need for fractional asset transactions, particularly important for stable coin implementations. When creating a US dollar-based stable coin, the recommended decimal display setting of six provides substantial precision. This means that what appears as one dollar of the stable coin is actually represented internally as one million base units (1,000,000), ensuring users can send precise amounts including fractions of cents while maintaining mathematical precision. - -Scaling factors represent an additional layer of precision management operating at the computational level. While decimal display addresses user-facing precision requirements, scaling factors ensure that underlying mathematical operations maintain accuracy throughout the calculation process. This additional scaling makes internal numbers even larger during processing, preventing precision loss that could occur with floating-point arithmetic operations. - -The build process follows standard Go development practices, utilizing the provided Makefile for compilation. Once built, the resulting binary can be deployed to the appropriate location on the server, typically in the standard Go binary directory. System service management through systemd provides reliable oracle operation with automatic restart capabilities and proper logging integration, ensuring the oracle starts automatically on system boot and maintains consistent operation. - -### Node Configuration and Practical Demonstration - -Integrating a price oracle with a Lightning Network daemon requires minimal configuration changes, accomplished through a single configuration line specifying the oracle's network location. For nodes running their own local price oracle, the configuration simply references localhost with the appropriate port number. Nodes accessing a remote price oracle specify the IP address or hostname of the oracle server instead. This flexibility allows for both centralized oracle services serving multiple nodes and distributed architectures where each node maintains its own oracle instance. - -The demonstration environment consists of two signet nodes configured to showcase the complete RFQ workflow. The primary node functions as an edge node, running both the Lightning Network daemon and the price oracle service, maintaining channels with various assets and serving as the conversion point between different asset types. The secondary node operates as a client, holding asset balances and initiating transactions requiring price oracle consultation. - -Invoice creation demonstrates the sophisticated asset handling capabilities of the modern Lightning Network implementation. When creating an invoice for asset payments, the system allows specification of group keys rather than specific asset IDs, providing flexibility for fungible asset families like stable coins. The invoice creation command includes the asset amount requested, the group key for acceptable assets, and the RFQ public key identifying the edge node that will facilitate the conversion. - -Payment execution involves automatic consultation of the price oracle to determine the appropriate conversion rate. When the paying node processes the asset invoice, it contacts the specified edge node's price oracle to request a quote for the conversion. The oracle responds with precise calculations based on current market conditions, asset characteristics, and specific amounts involved in the transaction. This automation eliminates manual calculation while ensuring fair market-based pricing for all parties. - -### Validation and Best Practices - -Verification of the price oracle's accuracy involves comparing actual transaction results against expected calculations based on the oracle's reported Bitcoin price and asset amounts involved. The demonstration includes a comprehensive spreadsheet tool performing these calculations, allowing users to verify that oracle quotes and resulting transactions produce mathematically correct results. - -The verification process examines several key metrics: the Bitcoin price reported by the oracle during the transaction, the number of asset units transferred, the equivalent Bitcoin value calculated by the oracle, and final channel balance changes on both nodes. When these values align with mathematical expectations based on the oracle's pricing, it confirms the system operates correctly and provides fair, accurate conversions. - -Log files generated by the price oracle provide additional verification data, showing the exact Bitcoin price used for calculations and the timestamp of the pricing query. This information enables precise reconstruction of the oracle's decision-making process and validates that pricing information was current and accurate at transaction time. - -Key considerations for production deployments include implementing robust price feeds from multiple sources, carefully configuring asset support policies, and maintaining comprehensive logging for audit and debugging purposes. The decimal display and scaling factor configurations require careful consideration based on specific assets being supported and precision requirements of intended use cases. - -The RFQ system's flexibility in supporting both individual asset IDs and group keys makes it particularly well-suited for stable coin implementations and other scenarios where multiple related assets should be treated as fungible. This capability, combined with automated pricing provided by oracles, creates a powerful foundation for building sophisticated financial applications on the Lightning Network while maintaining the decentralized, trustless characteristics that make Bitcoin-based systems attractive. - - -# Final Section -9469342a-870c-11f0-88da-ff4cff486fe3 - -## Evaluate this course -20570fc0-87e9-11f0-bdd0-cff9e0b16538 -true - -## Conclusion -43393838-870d-11f0-b490-cb9bbebd87d5 -true - - - - -