Author: Ruben Somsen 2022-04-10 16:51:52
Published on: 2022-04-10T16:51:52+00:00
Ruben and Olaoluwa were discussing the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation, which was unhelpful and maze-like, and he received poor responses when he asked questions about it. Due to his experience, Ruben thought that rebuilding Taro from scratch was the right decision. However, he believed that Taro should still credit RGB in its documentation because Taro's design seemed to have been inspired by RGB. 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. For example, strongly binding all assets to Bitcoin UTXOs and covenants allowing Bitcoin Script to bind Taro state transitions were discussed. Ruben explained some potential issues with Taro's system, such as asset issuers choosing to issue assets in denominations instead of allowing them to be fully divisible. Additionally, he mentioned that the location of the Taro tree inside the taproot tree must be deterministic and the output in which the Taro tree is placed needs to be determined as well to prevent secret forking of the history. Finally, Ruben clarified the purpose of the sparse merkle tree in the Taro design, which allows for non-inclusion proofs and a history-independent structure. On the other hand, Laolu, the developer of MIMO, shared an update on the project's progress. He described the tree structure used by the protocol, which allows for easy tracking of issuance events and uniqueness of certain items/commitments. Laolu also explained how validation is made simpler through the use of merkle-sum traits. Regarding transferring Taro token ownership from one Bitcoin UTXO to another, Laolu explained that for interactive transfers, only the UTXOs generated as part of the MIMO transaction are used. For sending via the address format, a new non-dust output is created which holds the new commitment and uses an internal key provided by the receiver so that only they can move the UTXO.
Updated on: 2023-06-15T18:35:09.162833+00:00