Published on: 2022-11-07T13:51:12+00:00
During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins. "The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets.
Updated on: 2023-08-02T05:59:12.664244+00:00