Author: Johan Torås Halseth 2022-11-03 09:26:05
Published on: 2022-11-03T09:26:05+00:00
In a recent discussion, Johan suggested that the "teleport" feature used by RGB protocol could be useful in an LN setting for Taro. Currently, to transfer tokens in Taro, users have to spend a UTXO and provide proof showing that tokens are committed to the output they are spending from. However, with the teleport feature, users can still spend a UTXO but only need to provide proof that some transaction output has committed tokens to their UTXO. This allows for exciting possibilities such as adding tokens to already open channels or topping up multiple channels at once. Additionally, the feature allows for blinding of the UTXO, which is useful when wanting to withdraw tokens from an exchange directly into an LN channel without revealing the channel UTXO.Ruben raised concerns about the abundance of documentation but a lack of clear mapping of the fundamental design with regards to the RGB protocol. He also expressed disappointment in the poor response he received when asking questions related to it. Despite these issues, Ruben believes that the RGB protocol should be credited in the Taro documentation as its design precedes and seems to have inspired Taro. Furthermore, Ruben explains that scripting support in Taro does not make sense due to limitations that prevent anything interesting from being built. However, with TAPLEAF_UPDATE_VERIFY, Taro transitions can be further bound at the Bitcoin level without Bitcoin explicitly needing to be aware. Ruben also discussed the potential for an asset issuer to do a "re-genesis" that can work under certain circumstances. He notes that this won't help for tokens that aim to have a publicly audited supply, and the idea requires the issuer to be active.When asked about how the teleport feature works, Ruben explained that it involves pointing to the outpoint of an existing UTXO owned by the recipient instead of creating a new output. However, this requires ensuring that the recipient does not spend from this output while tokens are simultaneously being sent to it. Finally, Ruben explains that the location of the Taro tree inside the taproot tree, as well as the output in which the Taro tree is placed, need to be deterministic for the verifier.The Taro protocol, designed as an upgrade to Bitcoin Script, allows for the implementation of covenants that bind state transitions in Taro without bleeding over into Bitcoin logic. The system's core is relatively simple with a compact implementation thanks to reusing Bitcoin's context and design. Asset issuers can choose to issue assets in denominations or keep them fully divisible. To keep asset histories compressed, the primary way is through compatibility with the Lightning Network layer. The Taro tree's location inside the taproot tree is not fixed to prevent showing different histories to different people. There are three options: require the Taro commitment to be in the first/last position within the Tapscript tree, include the position of the Taro commitment within the Tapscript tree within the sighash digest, or include the position of the Taro commitment within the Tapscript tree as part of the message that's hashed to derive asset IDs. The sparse merkle tree has four key functions: non-inclusion proofs, tree structure history independence, ensuring uniqueness of certain items/commitments, and merkle-sum trait simplifying validation.For interactive transfers, UTXOs generated are part of the MIMO transaction. When 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 only they can move the UTXO. Laolu Akinyele is updating the draft over the next few days following feedback and analysis.
Updated on: 2023-06-03T08:18:07.193139+00:00