Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
Hey Laolu, Really interesting protocol. I'm not all the way through all of the docs yet, but had a few questions/comments: - The top-level doc ( https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks about embedding overlay metadata in the taproot script tree. From my reading, it seems like what gets committed is the root of the taro MS-SMT tree, while leaves of the tree itself are off-chain in a proof file. If that's the case, did you look at other mechanisms to commit to a merkle root? For example, I believe mainstay[1] uses a pay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to p2pkh/p2sh addresses with signature tweaks. Are there other interesting (to taro) spend-paths that need to be allowed that led to the taproot script tree being particularly helpful? - It appears that the transfer proofs are kept off-chain in another file which is passed between users, where the receiver can validate the transfer according to whatever semantics the taro-vm has at that moment and refuse to credit the sender if the transfer breaks some business logic or validation rules. This reminds me a lot of single-use-seals[3]. Is that the right way to think about what's going on here? If it is, then it looks like a Universe/Multiverse is an offload/aggregation mechanism that can keep track of asset lineages on behalf of users, which would be useful for light clients of heavily-used asset types (so your mobile client doesnt have to traverse the transfer lineage of some high-liquidity stablecoin or something). - Rubin made a good point above about how something like a conditional transfer in a taro asset won't necessarily cause the conditional bitcoin transfer to fail. My first thought was to have the "carrier utxo" for a taro asset be really small, like dust + some buffer. The thought being that I'm basically just paying gas and if I lose `dust+buffer` amount of bitcoin but not a lot of some token, then that's not great but not terrible. Where it gets bad is if the value of the taro asset that you're trying to transfer is close to or less than the value of the bitcoin that's being used to do the transfer. - There's been a lot of talk lately on the bitcoin-dev list about covenants, and I wonder if some of those designs (specifically TLUV or CTV) might be useful with Taro, to "lift" some of the taro conditions into covenants that encumber the underlying bitcoin. I don't have a design or anything, wondering if you've given this any thought. - was this originally named CMYK? Thanks, Alex [1] https://cloudflare-ipfs.com/ipns/ipfs.commerceblock.com/commerceblock-whitepaper-mainstay.pdf [2] https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki [3] https://petertodd.org/2016/commitments-and-single-use-seals On Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen wrote: > Hi Laolu, > > Nice work. This is an interesting protocol, in my opinion. > > Seeing as there's a large amount of overlap with RGB, a protocol which I > have examined quite extensively, I believe some of the issues I uncovered > in that project also apply here. > > The biggest issue revolves around the scripting expectations for this > protocol. Taro is described as being able to have its own scripting > capabilities that will initially be similar to Bitcoin and eventually be > made to do more. I'm afraid this is fundamentally impossible. Conditional > scripts (and thus most scripts that could potentially be of interest) won't > be possible if the satisfaction of the condition is not recorded publicly > on-chain. > > The core problem here is that you have two levels of scripting. At the > Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the > Taro level you have yet another script. This may seem similar at first > glance to how taproot has a key path and a script path, but there are a few > key differences. In taproot only one of the two needs to be satisfied, > while here you need to satisfy both. Furthermore, the Taro script is not > enforced by Bitcoin, meaning those who control the Bitcoin script can > always choose to ignore the Taro script and destroy the Taro assets as a > result. > > I'll describe an example. Imagine Alice wants to send Bob a payment inside > Taro, but she wants to make it conditional. Bob gets the Taro tokens if he > reveals a pre-image, while Alice can claim the tokens back after the > timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice > starts by locking up coins in a 2-of-2 multisig on the mainchain with some > Taro tokens inside. She then gives Bob a pre-signed transaction that only > requires him to reveal the pre-image in order to claim the tokens. The > issue here is that from Bitcoin's perspective, you're giving Bob a valid > transaction, regardless of whether he reveals the pre-image. If Bob > maliciously broadcasts it without the pre-image, he will have destroyed > your tokens. > > Of course this was a contrived example, as these conditions
Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Hi Laolu, Nice work. This is an interesting protocol, in my opinion. Seeing as there's a large amount of overlap with RGB, a protocol which I have examined quite extensively, I believe some of the issues I uncovered in that project also apply here. The biggest issue revolves around the scripting expectations for this protocol. Taro is described as being able to have its own scripting capabilities that will initially be similar to Bitcoin and eventually be made to do more. I'm afraid this is fundamentally impossible. Conditional scripts (and thus most scripts that could potentially be of interest) won't be possible if the satisfaction of the condition is not recorded publicly on-chain. The core problem here is that you have two levels of scripting. At the Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the Taro level you have yet another script. This may seem similar at first glance to how taproot has a key path and a script path, but there are a few key differences. In taproot only one of the two needs to be satisfied, while here you need to satisfy both. Furthermore, the Taro script is not enforced by Bitcoin, meaning those who control the Bitcoin script can always choose to ignore the Taro script and destroy the Taro assets as a result. I'll describe an example. Imagine Alice wants to send Bob a payment inside Taro, but she wants to make it conditional. Bob gets the Taro tokens if he reveals a pre-image, while Alice can claim the tokens back after the timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice starts by locking up coins in a 2-of-2 multisig on the mainchain with some Taro tokens inside. She then gives Bob a pre-signed transaction that only requires him to reveal the pre-image in order to claim the tokens. The issue here is that from Bitcoin's perspective, you're giving Bob a valid transaction, regardless of whether he reveals the pre-image. If Bob maliciously broadcasts it without the pre-image, he will have destroyed your tokens. Of course this was a contrived example, as these conditions could simply take place entirely in Bitcoin script, but it demonstrates that Taro script fundamentally cannot handle conditional payments, which is the basis for any meaningful script other than self-encumbering covenants (i.e. if you send your Taro tokens in any way other than specified, the tokens will be destroyed). Luckily this has no effect on whether Taro can function over Lightning, because solely relying on Bitcoin's scripting capabilities should be sufficient for that use case. As a side note, it may be worth pointing out that it *is* possible to create conditional payments if the satisfaction of the condition is recorded publicly on the mainchain (e.g. in an op_return), making it sort of a hybrid on-chain/off-chain model, but it would increase complexity considerably. I can explain this model in more detail, if it happens to interest you. Now there's a second issue I want to bring up, but unfortunately my understanding of how exactly you made assets divisible is not complete enough to know how this problem might have manifested in Taro. Nonetheless, I'll try to describe it. One of the core concepts of Taro/RGB is that the sender of the token has to reveal the history to the recipient. In case of an NFT the history is simply every prior owner and grows linearly, but in the case of fungible tokens things are more complicated. Let's say Carol receives 2 fungible Taro tokens from Alice and 3 fungible Taro tokens from Bob. Now Carol wants to send 4 of them to Dave and keep 1. There are two possible designs here: a.) The token history remains separate – Dave receives Alice's 2 tokens, Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice). b.) The token history gets merged – Dave receives 4 tokens (linking the new output with both Alice and Bob's history). The issue with a.) is that you're only ever fragmenting tokens, so eventually you end up with lots of tiny but separate amounts. This will cause making large payments to involve sending lots of tokens, each with their own history. Under this model, I suspect the fixed value token model (e.g. 1, 2, 4, 8) might be preferable, as this prevents the entire supply from getting split into tiny fragments. The issue with b.) is that you end up with a linked transaction graph, just like in Bitcoin. If you pick a random Bitcoin UTXO and try to trace it back to a coinbase, you'll quickly find that it could have come from many of them. The graph that you'd traverse to get to all of these coinbases is equivalent to the amount of history that a recipient of a Taro token has to validate in order to accept it, which I suspect quickly becomes a bottleneck that is not unlike that of a regular blockchain. It'd probably be wise to make a model of the potential transaction flow, and simulate how it affects the size of the history in order to determine what's the best approach and to generally get a
