Propose new BIP for Programmable Bitcoin Token Standard (PBTS) #1787
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,305 @@ | ||
| # BIP-XXXX: Programmable Bitcoin Token Standard (PBTS) | ||
|
|
||
| ``` | ||
| BIP: XXXX | ||
| Layer: Applications | ||
| Title: Programmable Bitcoin Token Standard (PBTS) | ||
| Author: Gobi Shanthan <[email protected]>, Lee Raj. <[email protected]> | ||
| Comments-Summary: No comments yet. | ||
| Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX | ||
| Status: Draft | ||
| Type: Standards Track | ||
| Created: 2025-02-11 | ||
| License: BSD-2-Clause | ||
| Discussions-To: [email protected] | ||
| Post-History: 2025-02-11 | ||
|
There was a problem hiding this comment. I don’t seem to have any emails received via the Bitcoin Developer Mailing List that pertain to this proposal. |
||
| Requires: 340, 341, 342 | ||
| ``` | ||
|
|
||
| ## Abstract | ||
|
|
||
| The **Programmable Bitcoin Token Standard (PBTS)** introduces a method to create, transfer, and validate native Bitcoin-based tokens using **Bitcoin Script** and **Taproot**. PBTS enhances Bitcoin's Layer 1 functionality by enabling **tokenized assets** with programmable conditions without compromising security, decentralization, or predictability. Unlike Ethereum or Solana, PBTS **does not introduce Turing-complete smart contracts** but leverages **structured pre-commitments** and **Taproot optimizations** to enable secure, efficient programmable tokens. | ||
|
There was a problem hiding this comment. E.g., here and in many other places it still says "PBTS" |
||
|
|
||
| PBTS is a **non-consensus-breaking, backward-compatible** standard that ensures tokens remain verifiable and transferable without requiring modifications to Bitcoin's core protocol. | ||
|
|
||
| ## Copyright | ||
|
|
||
| This BIP is licensed under the BSD 2-clause license. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Bitcoin adheres to the principles of **minimalism and security**, which have made it the most robust and decentralized blockchain. PBTS aligns with this philosophy by introducing **programmability without complexity**, ensuring that Bitcoin's core remains unchanged while extending its utility in a predictable and efficient way. | ||
|
|
||
| Bitcoin currently lacks a **native** token standard that enables **flexible** and **fully Layer 1** token issuance with programmable conditions. Existing solutions such as **Ordinals, RGB, and Runes** either rely on **external tracking mechanisms** or **Layer 2 solutions** that introduce centralization risks. PBTS provides a **UTXO-based**, predefined, and non-intrusive method for issuing tokens that remain completely **verifiable on Bitcoin's base layer** with advanced programmable features like time-locked vesting and milestone-based escrow. | ||
|
There was a problem hiding this comment. In the Motivation, could you please expand on the issue this proposal addresses and how this proposal improves Bitcoin? It’s not obvious to me how a token standard improves Bitcoin. It is an open question whether colored coin protocols and other token schemes are on-topic for this repository. There was a problem hiding this comment. We initially submitted TBS as a standard BIP, but it should have been an informational BIP—apologies for the mistake. Regarding comparisons, I understand skepticism about another token standard; TBS isn’t meant to replace others but to provide a more Bitcoin-native approach that aligns with its security and validation model. While it’s an open question whether token protocols belong in this repository, token activity is already happening on Bitcoin (e.g., Ordinals), often inefficiently. TBS aims to improve Bitcoin by offering a structured, UTXO-based standard that optimizes Taproot, reducing blockchain bloat and improving transaction efficiency compared to ad-hoc tokenization methods. There was a problem hiding this comment. There seems to be a misunderstanding here. I am not complaining about the type of the BIP, I’m pointing out that many members of this community are of the opinion that this repository should only collect proposals that further the Bitcoin currency. Colored coin protocols and token standards are inherently about other assets. |
||
|
|
||
| ## Key Benefits | ||
|
|
||
| 1. **No Additional Layers** | ||
| * Execution happens directly in **Bitcoin transactions** | ||
| * Complete validation on **Layer 1** | ||
| * No external dependencies for validation | ||
|
|
||
| 2. **Predefined & Deterministic Execution** | ||
| * No infinite loops or dynamic state modifications | ||
| * Predictable execution paths | ||
| * Fixed state transitions | ||
|
|
||
| 3. **Minimal Impact** | ||
| * Utilizes existing **Taproot** and **Script** functionality | ||
| * No consensus changes required | ||
| * Standard transaction format | ||
|
|
||
| 4. **Scalability & Efficiency** | ||
| * **Merkle proof-based validation** | ||
| * Minimal transaction sizes through Taproot optimization | ||
| * Compatible with future Bitcoin scaling solutions | ||
|
|
||
| 5. **Security Model** | ||
| * No external validators required | ||
| * Fully **self-custodial** | ||
| * Bitcoin-native security | ||
|
|
||
| 6. **Programmable Conditions** | ||
| * Time-locked transfers (vesting) | ||
| * Milestone-based escrow with multiple release stages | ||
| * Multi-signature requirements | ||
| * Prepared for oracle integration | ||
|
|
||
| ## Comparison with Existing Bitcoin Token Standards | ||
|
|
||
| | Feature | Ordinals | Runes | PBTS | | ||
|
There was a problem hiding this comment. It seems to me that you might mean "BRC20" tokens here, when you refer to "Ordinals". The term Ordinals refers to a concept of assigning serial numbers to each satoshi in the order they were minted and tracking these satoshis per some defined rules through the history of the Bitcoin transaction graph. |
||
| |----------------------------|--------------------------|-----------------|------------------------------| | ||
| | UTXO-Based | ❌ No (Inscriptions) | ✅ Yes | ✅ Yes | | ||
| | Requires External Indexer? | ✅ Yes | ✅ Yes | ❌ No | | ||
| | Efficient for Tokens? | ❌ No | ✅ Somewhat | ✅ Fully Optimized | | ||
| | Scalability Impact | ❌ High Blockchain Bloat | ⚠️ Medium | ✅ Minimal (Uses Taproot) | | ||
| | Bitcoin Script-Based? | ❌ No | ✅ Yes | ✅ Yes (Taproot-Optimized) | | ||
| | Consensus Changes Required?| ❌ No | ❌ No | ❌ No | | ||
| | Transaction Cost | ❌ Expensive | ⚠️ Medium | ✅ Efficient | | ||
| | Programmable Conditions | ❌ No | ⚠️ Limited | ✅ Yes | | ||
| | Fully On-Chain Validation | ❌ No | ❌ No | ✅ Yes | | ||
|
|
||
| ## Specification | ||
|
There was a problem hiding this comment. The Specification section should provide a formal description of the new feature that is precise and comprehensive enough to allow implementation of the feature. |
||
|
|
||
| ### Overview | ||
|
|
||
| PBTS tokens are created, transferred, and validated directly on Bitcoin's Layer 1 using Taproot scripts to enable complex programmable conditions without requiring any modifications to the Bitcoin protocol. | ||
|
|
||
| ### Token Creation | ||
|
|
||
| A **PBTS token** is created by locking a **UTXO** with a **Taproot script** that commits to a token issuance structure. The token metadata is encoded in the transaction output using a standardized format: | ||
|
|
||
| 1. **Token Issuance Format**: | ||
| * The output script is a Taproot output that contains: | ||
| * Token ID: A 32-byte identifier (Hash of Issuer's Public Key + Script Hash) | ||
| * Total Supply: Fixed integer representing the maximum possible supply | ||
| * Decimals: Integer representing the decimal places (typically 8 to match satoshis) | ||
| * Metadata Commitment: Optional hash of off-chain metadata (name, symbol, description) | ||
|
Comment on lines
+92
to
+97
There was a problem hiding this comment. You claim that no consensus change is necessary, but it is not clear to me how the special meaning of this new output type is supposed to be enforced without new consensus rules. Could you perhaps clarify this point? There was a problem hiding this comment. TBS doesn't require consensus changes because it doesn't introduce any "special meaning" at the consensus level. Instead, it uses existing Bitcoin Script capabilities to create self-enforcing token rules. Where token_metadata_hash is a hash of the token's properties including ID and supply. To spend a token output, the transaction must provide valid signatures and satisfy all script conditions Crucially, this doesn't require Bitcoin nodes to understand the concept of "tokens" - they simply enforce normal script execution rules. The token semantics are interpreted by compatible wallet software, but the validation happens through standard Bitcoin transaction verification. There was a problem hiding this comment.
The leaf script is processed as follows. The signature is pushed on the stack, the hash is pushed on the stack, the hash is dropped, the pubkey is pushed on the stack, then OP_CHECKSIG checks whether the signature is a valid signature of the transaction by the private key corresponding to the pubkey. Please elaborate how this script commits to the token properties and how that can be used to enforce and validate the tokens.
As described, the token_metadata_hash is just dropped, so as far as I can tell, any data can be provided here to the same effect.
The only relevant condition that I see here appears to require a signature from a specific key.
How is it enforced that subsequent outputs preserve the token properties? I do not see any mechanism that encumbers the subsequent outputs, nor does the above described output script require any such thing. What transaction introspection mechanism are you using to read the "token_metadata_hash" from the prior output? How is it ensured that the new outputs contain the identical script commitments. Are you proposing new consensus rules that enforce this? If so, what are these new consensus rules? It seems to me that if you can pull this off without new consensus rules, the proponents fighting for several years to introduce some covenant proposals would be excited to learn in detail how you manage to do that.
How is the token amount preserved? We threw away the token_metadata_hash in the output script, and we don’t have any mechanism to enforce any properties for the new outputs.
The described scripts indeed do not require Bitcoin nodes to understand anything about tokens, because they in fact simple ignore all information about the tokens and only enforce the normal script execution rules, which do not whatsoever seem to ensure the persistence of tokens.
If the token semantics are only interpreted by compatible wallet software, we are talking about a client-side validation scheme.
No? OP_CHECKMULTISIG and OP_CHECKSIGADD are part of the Script language and explicitly count the number of signatures. |
||
|
|
||
| 2. **Example Issuance Script**: | ||
| ``` | ||
| <token_metadata_hash> OP_DROP | ||
| <issuer_pubkey> OP_CHECKSIG | ||
| ``` | ||
|
|
||
| ### Token Contracts | ||
|
|
||
| PBTS supports several programmable contract types that define how tokens can be transferred and under what conditions they can be spent: | ||
|
|
||
| #### 1. Auto-Vest (Time-Locked) Contracts | ||
|
|
||
| Time-locked transfers where tokens become available to the recipient only after a specific date, using Bitcoin's CHECKLOCKTIMEVERIFY opcode. | ||
|
|
||
| **Script Pattern**: | ||
| ``` | ||
| IF | ||
| <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP | ||
| <receiver_pubkey> OP_CHECKSIG | ||
| ELSE | ||
| <issuer_pubkey> OP_CHECKSIG | ||
| ENDIF | ||
| ``` | ||
|
Comment on lines
+114
to
+121
There was a problem hiding this comment. This script appears to allow the issuer to always spend the UTXO and the recipient to also spend the UTXO after some time. The script does not seem to exhibit any characteristics that enforce any special behavior regarding tokens. |
||
|
|
||
| #### 2. Milestone-Based Escrow | ||
|
|
||
| Structured transfers with multiple release stages, each requiring specific conditions like time thresholds and multi-signature approvals. | ||
|
|
||
| **Script Pattern**: | ||
| ``` | ||
| IF | ||
| # Milestone 1 | ||
| <milestone1_locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP | ||
| <m1> <pubkey1> <pubkey2> <pubkeyN> <n> OP_CHECKMULTISIG | ||
| ELSEIF | ||
| # Milestone 2 | ||
| <milestone2_locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP | ||
| <m2> <pubkey1> <pubkey2> <pubkeyN> <n> OP_CHECKMULTISIG | ||
| ELSEIF | ||
| # Expiry condition (return to sender) | ||
| <expiry_time> OP_CHECKLOCKTIMEVERIFY OP_DROP | ||
| <sender_pubkey> OP_CHECKSIG | ||
| ENDIF | ||
|
Comment on lines
+129
to
+141
There was a problem hiding this comment. This may be describing a decaying multisig, but again doesn’t appear to introduce any handling of tokens. |
||
| ``` | ||
|
|
||
| #### 3. Oracle-Ready Contracts | ||
|
|
||
| Contracts designed to work with external data oracles, containing placeholder structures for future oracle implementation. | ||
|
|
||
| **Script Pattern**: | ||
| ``` | ||
| IF | ||
| # Oracle verification | ||
| <oracle_pubkey> OP_CHECKSIGVERIFY | ||
| <condition_hash> OP_SHA256 <expected_result_hash> OP_EQUALVERIFY | ||
| <receiver_pubkey> OP_CHECKSIG | ||
| ELSEIF | ||
| # Expiry condition (return to sender) | ||
| <expiry_time> OP_CHECKLOCKTIMEVERIFY OP_DROP | ||
| <sender_pubkey> OP_CHECKSIG | ||
| ENDIF | ||
| ``` | ||
|
|
||
| ### Token Transfer | ||
|
|
||
| PBTS token transfers involve creating transactions that spend from token-containing UTXOs and create new UTXOs with the appropriate scripts to maintain token properties and conditions. | ||
|
|
||
| 1. **Standard Transfer**: | ||
| * Spends from a token UTXO | ||
| * Creates new outputs with token metadata preserved | ||
| * May split tokens across multiple outputs (for partial transfers) | ||
|
Comment on lines
+166
to
+169
There was a problem hiding this comment. I seem to be missing something. How are these transactions fashioned to enforce adherence to the token supply limit? There was a problem hiding this comment. Thank you for your question on token supply enforcement. This is indeed a critical aspect of the proposal. Genesis Commitment: Conservation in Transfers: Spend from one or more UTXOs containing token commitments Example Transfer Mechanism: // Outputs The key insight is that Bitcoin's existing UTXO model inherently enforces conservation: You can only spend what exists By encoding token amounts directly in the output scripts and requiring validation of these values during transfers, the supply limit is enforced through regular Bitcoin transaction validation rules. There was a problem hiding this comment.
While there is a proposal to reinstate OP_CAT in Tapscript, it is currently not part of Bitcoin’s Script language or Tapscript language, so I’m afraid, that this does not match your prior claim that your proposal doesn’t require consensus change. Further, none of the inputs to the OP_EQUALVERIFY in the following depend on the content of the transaction.
So, this is trivially true, regardless of where you direct the funds from the UTXO.
You seem to be describing the intended behavior, but the point of a Specification is to provide precise and comprehensive instructions how this behavior is achieved.
How do you enforce that a transaction is only valid when the two output amounts match the "token_amount_in". Where was "token_amount_in" provided? Where are these values compared? How does validation fail when they don’t add up?
I have yet to see a hint of a mechanism that enforces metadata consistency.
Sounds great in theory, however, I seem to be unable to find a description of the mechanism that enforces token commitments, or amount consistency. |
||
|
|
||
| 2. **Conditional Transfer**: | ||
| * Creates outputs with Taproot scripts encoding the conditional logic | ||
| * Enables time-locked, multi-signature, or other programmable conditions | ||
|
|
||
| 3. **Transaction Validation**: | ||
| * Follows standard Bitcoin transaction validation rules | ||
| * Leverages Bitcoin's native UTXO model for tracking ownership | ||
| * Enables verification without external indexers or oracles | ||
|
|
||
| ### Implementation Details | ||
|
|
||
| #### Taproot Integration | ||
|
|
||
| PBTS leverages Taproot's script path spending to enable complex script execution while maintaining payment efficiency: | ||
|
|
||
| 1. **Key Path Spending**: | ||
| * Used for standard transfers with no conditions | ||
| * Minimizes transaction size and fees | ||
|
|
||
| 2. **Script Path Spending**: | ||
| * Used for conditional transfers (time locks, multi-sig, etc.) | ||
| * Reveals only the relevant script path when executing | ||
|
|
||
| 3. **Commitment Structure**: | ||
| * Main output key commits to all possible spending paths | ||
| * Each condition is a separate script leaf in the Taproot tree | ||
|
|
||
| #### On-Chain Token State Tracking | ||
|
|
||
| PBTS tokens maintain their state entirely on-chain: | ||
|
|
||
| 1. **Token Properties**: | ||
| * All token properties are verifiable through transaction outputs | ||
| * Token metadata is committed via hashes in the script structure | ||
|
|
||
| 2. **Ownership Tracking**: | ||
| * Token ownership is represented by control of the corresponding UTXOs | ||
| * Standard Bitcoin wallet functionality can be used to track and manage tokens | ||
|
|
||
| ### Security Considerations | ||
|
|
||
| PBTS mitigates various attack vectors through: | ||
|
|
||
| 1. **Double Spending Prevention**: | ||
| * Each token is tied to a specific UTXO | ||
| * Standard Bitcoin consensus rules prevent double-spending | ||
|
|
||
| 2. **Replay Attack Protection**: | ||
| * Uses unique script conditions for each transfer | ||
| * Includes sequence numbers where appropriate | ||
|
|
||
| 3. **Fee Optimization**: | ||
| * Taproot implementation minimizes transaction sizes | ||
|
|
||
| 4. **Predictable Execution**: | ||
| * No dynamic loops or unpredictable execution paths | ||
| * All contract conditions are pre-defined at creation time | ||
|
|
||
| 5. **Time-Based Security**: | ||
| * Uses CHECKLOCKTIMEVERIFY to enforce time constraints | ||
| * Ensures time-locked funds cannot be spent prematurely | ||
|
|
||
|
|
||
| ### Prerequisites | ||
|
|
||
| * Bitcoin Core v28.1.0+ with RPC enabled | ||
| * Go 1.16 or newer | ||
| * A Bitcoin testnet or mainnet wallet with funds | ||
|
|
||
| ### Basic Usage | ||
|
|
||
| ```bash | ||
| # Issue a new token | ||
| ./pbts issue "Programmable Bitcoin Token" "PBTS" 8 1000000000 | ||
|
|
||
| # List all tokens | ||
| ./pbts list | ||
|
|
||
| # Create a time-locked vesting contract | ||
| ./pbts vest <token_id> <sender_pubkey> <receiver_pubkey> <amount> <unlock_date> | ||
|
|
||
| # Create a milestone-based escrow | ||
| ./pbts milestone <token_id> <sender> <receiver> <arbitrator> <amount> <milestone_count> \ | ||
| <milestone1_percentage> <milestone1_unlock_date> <milestone1_expiry_date> <milestone1_required_sigs> \ | ||
| <milestone2_percentage> <milestone2_unlock_date> <milestone2_expiry_date> <milestone2_required_sigs> | ||
| ``` | ||
|
|
||
| ## Examples | ||
|
|
||
| ### Time-Locked Vesting Contract | ||
|
|
||
| A successful time-locked vesting contract implemented on Bitcoin testnet: | ||
|
|
||
| ```bash | ||
| ./pbts vest 6ad138104a19ad3711a3ae6ec251f0c2 0234f63fb0b8acefb738a83f276ad6e5d18ec71613965c3f639f4158c3b07db1f4 03a7bd1d77432d2267813c908dca7ec7382a41a21a5da9e12d3726e63aae58bde3 10 2025-03-03 | ||
| ``` | ||
|
|
||
| Generated Output: | ||
| ``` | ||
| 🔄 Creating auto-vesting transfer of 10.000000 tokens (ID: 6ad138104a19ad3711a3ae6ec251f0c2) to 03a7bd1d77432d2267813c908dca7ec7382a41a21a5da9e12d3726e63aae58bde3 (unlocks at: 2025-03-03T00:00:00Z)... | ||
| Adjusting unlock time to ensure it's in the future: 2025-03-03T23:19:02-05:00 | ||
| Created Taproot address: tb1pkcvzu54pey9sjrj5qeu7xnvppe5k3w34spv7yhtfxxg56uyscsuq4uah44 | ||
| 🏦 Auto-Vest Address: tb1pkcvzu54pey9sjrj5qeu7xnvppe5k3w34spv7yhtfxxg56uyscsuq4uah44 (unlocks at: 2025-03-03T23:19:02-05:00) | ||
| ✅ Auto-vest transfer transaction broadcasted! TXID: 8c64767e003ed0b5786be07dac35b48eb32e53095af7802d5179808c36e7869d | ||
| ``` | ||
|
|
||
| This transaction (TXID: 8c64767e003ed0b5786be07dac35b48eb32e53095af7802d5179808c36e7869d) demonstrates a successful time-locked contract on Bitcoin testnet using Taproot functionality. | ||
|
|
||
| ## Backward Compatibility | ||
|
|
||
| PBTS is fully backward compatible with the existing Bitcoin protocol. It: | ||
|
|
||
| 1. Uses standard Bitcoin transactions | ||
| 2. Leverages existing opcode functionality | ||
| 3. Does not require any consensus changes | ||
| 4. Can coexist with other token standards | ||
|
|
||
| ## Test Vectors | ||
|
|
||
| [To be added in future update] | ||
|
|
||
| ## References | ||
|
|
||
| - **Bitcoin Improvement Proposals (BIPs):** | ||
| - [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) | ||
| - [BIP-342: Validation of Taproot Scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) | ||
| - [BIP-340: Schnorr Signatures](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) | ||
| - **Technical Documentation:** | ||
| - [Bitcoin Script Reference](https://en.bitcoin.it/wiki/Script) | ||
| - [UTXO Model Specification](https://developer.bitcoin.org/devguide/transactions.html) | ||
| - **Related Research:** | ||
| - [RGB Protocol](https://rgb.tech/) | ||
| - [Ordinals Specification](https://docs.ordinals.com/) | ||
| - [Runes Documentation](https://runes.com/docs/) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This title clashes with "PSBTs" and will lead to confusion should this BIP get adopted. Would you be open to considering a different name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, it is too similar in naming to PSBTs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your feedback! We recognize the potential confusion with PSBT (Partially Signed Bitcoin Transactions). To avoid this, we have renamed PBTS to TSB (Token Standard on Bitcoin). This ensures clarity and better represents the proposal's goal: establishing a unified standard for Bitcoin-native tokens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please update the title of this PR, the title of the BIP, and the content of the document to reflect the new name?