Propose new BIP for Programmable Bitcoin Token Standard (PBTS) #1787
Conversation
bip-pbst.md
Outdated
| ``` | ||
| BIP: XXXX | ||
| Layer: Applications | ||
| Title: Programmable Bitcoin Token Standard (PBTS) |
There was a problem hiding this comment.
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.
Agree, it is too similar in naming to PSBTs.
There was a problem hiding this comment.
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.
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?
bip-pbst.md
Outdated
|
|
||
| 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.
There was a problem hiding this comment.
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.
Agree with @murchandamus here. This proposal, along with token protocols in general, seem off-topic and out-of-scope for the bitcoin-dev mail list (was this proposal submitted there for feedback?) and the BIPs repository.
bip-pbst.md
Outdated
| 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) |
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.
Here's specifically how it works:
The token properties (like ID and supply) are committed to in standard Taproot outputs through Bitcoin Script patterns. For example:
<token_metadata_hash> OP_DROP
<issuer_pubkey> OP_CHECKSIG
Where token_metadata_hash is a hash of the token's properties including ID and supply.
When transferring tokens, spending conditions enforce token rules through standard script validation:
To spend a token output, the transaction must provide valid signatures and satisfy all script conditions
New outputs must preserve the token's properties through identical script commitments
The sum of token amounts in the outputs must match the inputs (preventing inflation)
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.
It's similar to how multisig wallets work - Bitcoin consensus rules don't understand the higher-level concept of "shared custody," but they enforce the script conditions that implement it.
There was a problem hiding this comment.
The token properties (like ID and supply) are committed to in standard Taproot outputs through Bitcoin Script patterns. For example:
<token_metadata_hash> OP_DROP
<issuer_pubkey> OP_CHECKSIG
The leaf script <hash> OP_DROP <pubkey> OP_CHECKSIG can be satisfied by providing merely a signature corresponding to the pubkey and the transaction in the witness:
<sig> <hash> OP_DROP <pubkey> OP_CHECKSIG
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.
Where token_metadata_hash is a hash of the token's properties including ID and supply.
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.
When transferring tokens, spending conditions enforce token rules through standard script validation:
To spend a token output, the transaction must provide valid signatures and satisfy all script conditions
The only relevant condition that I see here appears to require a signature from a specific key.
New outputs must preserve the token's properties through identical script commitments
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.
The sum of token amounts in the outputs must match the inputs (preventing inflation)
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.
Crucially, this doesn't require Bitcoin nodes to understand the concept of "tokens" - they simply enforce normal script execution rules.
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.
The token semantics are interpreted by compatible wallet software, but the validation happens through standard Bitcoin transaction verification.
If the token semantics are only interpreted by compatible wallet software, we are talking about a client-side validation scheme.
It's similar to how multisig wallets work - Bitcoin consensus rules don't understand the higher-level concept of "shared custody," but they enforce the script conditions that implement it.
No? OP_CHECKMULTISIG and OP_CHECKSIGADD are part of the Script language and explicitly count the number of signatures.
bip-pbst.md
Outdated
| 1. **Standard Transfer**: | ||
| * Spends from a token UTXO | ||
| * Creates new outputs with token metadata preserved | ||
| * May split tokens across multiple outputs (for partial transfers) |
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.
The token supply limit is enforced through a combination of transaction structure and script verification without requiring consensus changes:
Genesis Commitment:
When tokens are initially created, a specific UTXO contains the total supply commitment:
Copy<token_id> <total_supply> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <genesis_commitment_hash> OP_EQUALVERIFY
<issuer_pubkey> OP_CHECKSIG
Conservation in Transfers:
For any transfer, the transaction must:
Spend from one or more UTXOs containing token commitments
Create new outputs with identical token ID and metadata commitments
Ensure numerical conservation of the token amount
Example Transfer Mechanism:
Copy// Input
UTXO with token_amount_in (e.g., 100 tokens)
// Outputs
Output1: <token_id> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <token_commitment> OP_EQUALVERIFY <recipient1_pubkey> OP_CHECKSIG
Output2: <token_id> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <token_commitment> OP_EQUALVERIFY <recipient2_pubkey> OP_CHECKSIG
The transaction is only valid if amount1 + amount2 = token_amount_in
The key insight is that Bitcoin's existing UTXO model inherently enforces conservation:
You can only spend what exists
You can't double-spend the same UTXO
Script verification ensures the token metadata remains consistent
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.
No new outputs containing valid token commitments can be created without spending existing ones, and the amount validation in the scripts ensures no inflation occurs during transfers.
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. The token supply limit is enforced through a combination of transaction structure and script verification without requiring consensus changes:
Genesis Commitment: When tokens are initially created, a specific UTXO contains the total supply commitment: Copy<token_id> <total_supply> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <genesis_commitment_hash> OP_EQUALVERIFY <issuer_pubkey> OP_CHECKSIG
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.
<token_id> <total_supply> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <genesis_commitment_hash> OP_EQUALVERIFY <issuer_pubkey> OP_CHECKSIG
So, this is trivially true, regardless of where you direct the funds from the UTXO.
Conservation in Transfers: For any transfer, the transaction must:
Spend from one or more UTXOs containing token commitments Create new outputs with identical token ID and metadata commitments Ensure numerical conservation of the token amount
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.
Example Transfer Mechanism: Copy// Input UTXO with token_amount_in (e.g., 100 tokens)
// Outputs Output1: <token_id> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <token_commitment> OP_EQUALVERIFY <recipient1_pubkey> OP_CHECKSIG Output2: <token_id> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <token_commitment> OP_EQUALVERIFY <recipient2_pubkey> OP_CHECKSIG The transaction is only valid if amount1 + amount2 = token_amount_in
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?
The key insight is that Bitcoin's existing UTXO model inherently enforces conservation:
You can only spend what exists You can't double-spend the same UTXO Script verification ensures the token metadata remains consistent
I have yet to see a hint of a mechanism that enforces metadata consistency.
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. No new outputs containing valid token commitments can be created without spending existing ones, and the amount validation in the scripts ensures no inflation occurs during transfers.
Sounds great in theory, however, I seem to be unable to find a description of the mechanism that enforces token commitments, or amount consistency.
|
As I read it, this proposal is either a client-side validation scheme or requires a consensus change (or both), while claiming to be neither. The latter contradiction makes the comparison with existing schemes seem skewed. Especially, it is not at all obvious why this n-th standard for tokens is supposed to obsolete all others. This proposal should be improved to clarify what it is trying to achieve and how it is achieving that. There seems to be an underlying misunderstanding either about how consensus works or what mechanisms are necessary to achieve enforcement and validation as described in this document. I would appreciate it if future responses to questions were more to the point. The prior responses mostly repeat claims from the proposal, but barely address the main gist of my questions. Just because other networks have allowed themselves to be fully cannibalized by tokenization and the ensuing speculation and gambling, it is by no means obvious to me how tokens improve Bitcoin. |
|
Thank you for your thoughtful feedback. I appreciate your concerns and will address them directly: Regarding enforcement without consensus changes: On the apparent contradiction: I don't claim TBS would necessarily obsolete all others - different approaches have different tradeoffs. The goal is to offer a standard that minimizes blockchain bloat and aligns with Bitcoin's security model. I understand your concern about tokenization's effects on other networks. My observation is simply that token activity is already happening on Bitcoin, and a well-designed standard might help reduce negative externalities like excessive data storage. If you have any further questions, I would be happy to answer them. |
There was a problem hiding this comment.
This feature is at least heavily underspecified, if not outright technically unsound. This pull request seems premature to me: at the least it would require a more technically compelling description of the feature and a comprehensive Specification. If work is to continue on this effort, I would suggest exploring a proof of concept in regard to analyzing the enforcement properties of the described mechanism.
bip-pbst.md
Outdated
|
|
||
| ## 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.
bip-pbst.md
Outdated
| ``` | ||
| BIP: XXXX | ||
| Layer: Applications | ||
| Title: Programmable Bitcoin Token Standard (PBTS) |
There was a problem hiding this comment.
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?
bip-pbst.md
Outdated
|
|
||
| ## 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"
bip-pbst.md
Outdated
|
|
||
| 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.
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.
bip-pbst.md
Outdated
| | 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.
bip-pbst.md
Outdated
| 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) |
There was a problem hiding this comment.
The token properties (like ID and supply) are committed to in standard Taproot outputs through Bitcoin Script patterns. For example:
<token_metadata_hash> OP_DROP
<issuer_pubkey> OP_CHECKSIG
The leaf script <hash> OP_DROP <pubkey> OP_CHECKSIG can be satisfied by providing merely a signature corresponding to the pubkey and the transaction in the witness:
<sig> <hash> OP_DROP <pubkey> OP_CHECKSIG
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.
Where token_metadata_hash is a hash of the token's properties including ID and supply.
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.
When transferring tokens, spending conditions enforce token rules through standard script validation:
To spend a token output, the transaction must provide valid signatures and satisfy all script conditions
The only relevant condition that I see here appears to require a signature from a specific key.
New outputs must preserve the token's properties through identical script commitments
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.
The sum of token amounts in the outputs must match the inputs (preventing inflation)
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.
Crucially, this doesn't require Bitcoin nodes to understand the concept of "tokens" - they simply enforce normal script execution rules.
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.
The token semantics are interpreted by compatible wallet software, but the validation happens through standard Bitcoin transaction verification.
If the token semantics are only interpreted by compatible wallet software, we are talking about a client-side validation scheme.
It's similar to how multisig wallets work - Bitcoin consensus rules don't understand the higher-level concept of "shared custody," but they enforce the script conditions that implement it.
No? OP_CHECKMULTISIG and OP_CHECKSIGADD are part of the Script language and explicitly count the number of signatures.
bip-pbst.md
Outdated
| ``` | ||
| IF | ||
| <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP | ||
| <receiver_pubkey> OP_CHECKSIG | ||
| ELSE | ||
| <issuer_pubkey> OP_CHECKSIG | ||
| ENDIF | ||
| ``` |
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.
bip-pbst.md
Outdated
| 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 |
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.
bip-pbst.md
Outdated
| 1. **Standard Transfer**: | ||
| * Spends from a token UTXO | ||
| * Creates new outputs with token metadata preserved | ||
| * May split tokens across multiple outputs (for partial transfers) |
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. The token supply limit is enforced through a combination of transaction structure and script verification without requiring consensus changes:
Genesis Commitment: When tokens are initially created, a specific UTXO contains the total supply commitment: Copy<token_id> <total_supply> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <genesis_commitment_hash> OP_EQUALVERIFY <issuer_pubkey> OP_CHECKSIG
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.
<token_id> <total_supply> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <genesis_commitment_hash> OP_EQUALVERIFY <issuer_pubkey> OP_CHECKSIG
So, this is trivially true, regardless of where you direct the funds from the UTXO.
Conservation in Transfers: For any transfer, the transaction must:
Spend from one or more UTXOs containing token commitments Create new outputs with identical token ID and metadata commitments Ensure numerical conservation of the token amount
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.
Example Transfer Mechanism: Copy// Input UTXO with token_amount_in (e.g., 100 tokens)
// Outputs Output1: <token_id> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <token_commitment> OP_EQUALVERIFY <recipient1_pubkey> OP_CHECKSIG Output2: <token_id> <metadata_hash> OP_CAT OP_CAT OP_SHA256 <token_commitment> OP_EQUALVERIFY <recipient2_pubkey> OP_CHECKSIG The transaction is only valid if amount1 + amount2 = token_amount_in
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?
The key insight is that Bitcoin's existing UTXO model inherently enforces conservation:
You can only spend what exists You can't double-spend the same UTXO Script verification ensures the token metadata remains consistent
I have yet to see a hint of a mechanism that enforces metadata consistency.
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. No new outputs containing valid token commitments can be created without spending existing ones, and the amount validation in the scripts ensures no inflation occurs during transfers.
Sounds great in theory, however, I seem to be unable to find a description of the mechanism that enforces token commitments, or amount consistency.
bip-pbst.md
Outdated
| 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.
murchandamus
added
the
PR Author action required
|
Tend to suggest this PR be closed per discussions above (e.g. among others in #1787 (review) and #1787 (comment)) as out-of-scope, perhaps technically unsound, and not proposed beforehand on the bitcoin-dev mailing list. |
|
Given that the Specification does not appear to achieve what the proposal’s Abstract promises and there has been no response to the substantial review in over four weeks, I am going to close this PR. Please let us know if you are still working on this so we can reopen it, or open another PR after a new version of your idea has been presented to the mailing list. |
jonatack
removed
the
PR Author action required
|
I’m currently working on revisions and expect to have them ready soon.
I’ll post an updated version that addresses the feedback once it’s
finalized. Appreciate your patience, and I’ll follow up shortly.
…On Mon, Apr 14, 2025 at 5:34 PM murchandamus ***@***.***> wrote:
Given that the Specification does not appear to achieve what the
proposal’s Abstract promises and there has been no response to the
substantial review in over four weeks, I am going to close this PR. Please
let us know if you are still working on this so we can reopen it, or open
another PR after a new version of your idea has been presented to the
mailing list.
—
Reply to this email directly, view it on GitHub
<#1787 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARQZWIU3I2XQYVA6SHE5MX32ZQSVZAVCNFSM6AAAAABYTQILQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBTGA3TQMJZHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
*murchandamus* left a comment (bitcoin/bips#1787)
<#1787 (comment)>
Given that the Specification does not appear to achieve what the
proposal’s Abstract promises and there has been no response to the
substantial review in over four weeks, I am going to close this PR. Please
let us know if you are still working on this so we can reopen it, or open
another PR after a new version of your idea has been presented to the
mailing list.
—
Reply to this email directly, view it on GitHub
<#1787 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARQZWIU3I2XQYVA6SHE5MX32ZQSVZAVCNFSM6AAAAABYTQILQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBTGA3TQMJZHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
murchandamus
added
the
PR Author action required
|
Okay, I reopened this pull request |
|
Thank you
…On Tue, Apr 15, 2025 at 1:54 PM murchandamus ***@***.***> wrote:
Okay, I reopened this pull request
—
Reply to this email directly, view it on GitHub
<#1787 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARQZWISQ4TYFU7DN3G4ZJU32ZVBVXAVCNFSM6AAAAABYTQILQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGAZTANZQGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
*murchandamus* left a comment (bitcoin/bips#1787)
<#1787 (comment)>
Okay, I reopened this pull request
—
Reply to this email directly, view it on GitHub
<#1787 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARQZWISQ4TYFU7DN3G4ZJU32ZVBVXAVCNFSM6AAAAABYTQILQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGAZTANZQGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hi everyone, First, I just want to say thank you very much to everyone who took the time to review, ask questions, and challenge the original version of my proposal. I truly appreciate all the advice and critical feedback. It helped me realize many important points I had overlooked, and it gave me the opportunity to dive deeper, refine my thinking, and improve both the technical design and my understanding of Bitcoin’s principles. I’m sincerely grateful for the patience, the detailed technical explanations, and for pushing me to think more clearly. I would especially like to thank @murchandamus — your detailed feedback, questions, and explanations helped me significantly improve the proposal. I’d like to respond point-by-point to the key concerns raised previously:
Additional Notes: I have already updated the PR branch with the new TSB-P version based on the feedback. I am still actively working on refinements and would love to continue improving it with more input. I truly welcome any further comments, critiques, or suggestions to help make this proposal stronger and more aligned with Bitcoin’s philosophy. Once again, I am very thankful for the opportunity to learn from this process, and I deeply appreciate the time and energy the reviewers have invested. I look forward to continuing to improve based on your guidance and hope to eventually contribute something valuable back to the Bitcoin ecosystem. Please let me know how you'd prefer me to proceed — I’m ready to post to the mailing list if that would be helpful. Thank you again! 🙏 — Gobi Shanthan |
This pull request introduces a new Bitcoin Improvement Proposal (BIP):
Programmable Bitcoin Token Standard (PBTS)
PBTS provides a Layer 1 token standard leveraging Bitcoin Script and Taproot to enable the creation, transfer, and verification of native programmable tokens directly on Bitcoin. It introduces structured programmability without requiring changes to Bitcoin’s consensus rules.
Key Highlights:
Full details are available in the proposed BIP markdown file:
Feedback, suggestions, and discussion are welcome.