If you are unfamiliar with the Bitcoin Taproot upgrade and its implications, the following podcast is highly recommended.
Interviewer: So the primary reason to adopt Schnorr is just makes building advanced signing protocols easier?
Peter Wuille (Bitcoin Core): That is the number one reason why we want this.
Recent innovations in bitcoin, such as BIP 174, and the taproot upgrade, BIP 340, BIP 341, and BIP 342, enables developers to de-couple the signing experience from the orchestration of transactions. For example, BIP 174 introduced the now widely supported partially signed bitcoin transaction (PSBT) format for multisignature wallets.
Bitcoin orchestration is used to generate receiving addresses, verify ownership of treasuries, and proof of reserves reporting. The intermediate payloads (not private keys) may be encrypted or shared with a group. Compatible bitcoin signers include BlueWallet, in-browser via Hashed key vault, and more coming soon.
Users create an extended public key with their preferred signer, and verify that public key on Hashed Network (via QR code). When multiple users (or multiple accounts or security levels of the same user) attest to these keys on-chain, the pallet and off-chain workers orchestrate the process for signers.
BIP 174 supports a limited number of signers per wallet, and lacks the scalability and privacy-preserving features of taproot.
Taproot upgrade functionality (340/341) preserves privacy because the outputs are always Schnoor signatures that make complex functionality and single addresses publicly indistinguishable.
Pay-to-Taproot (P2TR) supports key and script aggregation in a hierarchy. This tree enables functionality for conditionally allowing spend of a UTXO. The Schnorr signature preserves privacy by only requiring a proof from the branch of the tree that satisfies the root condition.
As described by Moeller, it "provides user choice, meaning some transactions can be anonymous while others can stay public, depending on the use case. Tapscript validates these newer forms of transaction validity."
The ability to nest tapscript conditions enables a variety of expressive "smart contract" style functionality to build into bitcoin spends. For example, require extended approvals for larger amounts, wait periods, and additional tiers of hardware signers.
The bitcoin orchestrator generates the scripts and Schnoor addresses based on the configuration and business rules. The following diagram shows how a real-world spending policy would be translated to Tapscript and implemented with Hashed Network bitcoin orchestration.
No-Code Spending Policies
The BDK provides tools like Elephant, which was used to construct the spending policy below.
This policy expresses the rule that either the CEO can sign, both the CFO and COO, or either of them plus a 480 minute wait.
The spending policy is used to generate the receiving address. The UTXO is created at that address when it receives bitcoin. Then, when it is time to spend the UTXO, the orchestration builds 3 verifiable payloads, routes them to be signed, and then merges and broadcasts the resulting transaction.
With Schnorr key aggregation, no information about the spending policy is leaked. However, it is important for users to safely and securely manage the policy data to be able to reconstruct the signature requirements.
Coin control allows users to organize, combine, label, and sweep UTXOs. Businesses map transactions to general ledger income or expense accounts for proper bookkeeping. Users can export these ledgers as text files to be used in hledger and other plain text accounting tools. See On-chain Accounting for more.
Proof of Reserves
With coin control and accounting to properly manage the treasury, the information is well-organized for "proof-of-reserves". Treasurers can sign a single transaction that is combined with a report, that prove that the treasurer has access to the listed UTXOs.
Primary Benefits of Bitcoin Orchestration
- Verifiable/trustless receiving addresses and tapscript
- Coin control for labeling and grouping UTXOs with policies
- Integration with triple entry accounting systems
- Proof-of-Reserves reporting
- Active notifications to prompt approvers for signatures
- Integration with common pallets such as