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.
