Author: Ruben Somsen 2022-04-15 13:14:40
Published on: 2022-04-15T13:14:40+00:00
In an email exchange between Ruben Somsen and Olaoluwa Osuntokun, the former argues that it doesn't make sense to build scripting support into Taro as you can't actually do anything interesting with it due to limitations. Ruben identifies two exceptions to the "can't do scripting" rule: self-encumbrance and on-chain validation but believes that off-chain validation protocols can't do any meaningful scripting. He suggests that a regular scripting language for on-chain payments such as Bitcoin's is not going to cut it unless you have a very specific and compelling use case in mind that justifies the complexity. On the other hand, Olaoluwa thinks that the usage will be somewhat context-specific and dependent on the security properties one is after, suggesting an "issuance covenant" design sketch that may or may not be useful. This would allow a specified or generalized script to be validated when an asset issuance transaction is being validated. Ruben acknowledges that this seems like a useful primitive for creating assets that are somehow backed by on-chain BTC collateralization. Ruben suggests leaving out the scripting language altogether unless there is a specific and compelling use case that justifies the complexity. He believes that off-chain validation protocols can't do any meaningful scripting. Olaoluwa, however, thinks that there is still potential for scripting and suggests using an "issuance covenant" design sketch that would allow for certain collateralization requirements for issuing certain assets. Verifiers would only recognize that asset if the issuance covenant script passes, and the absolute timelock on those coins hasn't expired yet. Ruben also notes that adding op codes to verify proofs is sufficiently generalized compared to adding op codes to restrict the set of commitments to handle re-creating the Taro asset root. Finally, they discuss the location of the Taro tree inside the taproot tree and the output in which you place the Taro tree, which needs to be fully specified. Ruben suggests that a simple way to restrict this would just be to say it's always the first output or lift the output index into the asset ID calculation.
Updated on: 2023-06-03T08:15:49.968666+00:00