Hi Ruben, Thanks! I don't really consider things final until we have a good set of test vectors in the final set, after which we'd start to transition the set of documents beyond the draft state.
> 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. I'm happy to hear that someone was actually able to extract enough details from the RGB devs/docs to be able to analyze it properly! In the past I tried to ask their developers questions about how things like transfers worked[1][2], but it seemed either people didn't know, or they hadn't finished the core design (large TBD sections) as they were working on adding other components to create a "new new Internet". > 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. This is correct, as a result in most contexts, an incentive exists for the holder of an asset to observe the Taro validation rules as otherwise, their assets are burnt in the process from the PoV of asset verifiers. In the single party case things are pretty straight forward, but more care needs to be taken in cases where one attempts to express partial application and permits anyone to spend a UTXO in question. By strongly binding all assets to Bitcoin UTXOs, we resolve issues related to double spending or duplicate assets, but needs to mind the fact that assets can be burnt if a user doesn't supply a valid witness. There're likely ways to get around this by lessening the binding to Bitcoin UTXO's, but then the system would need to be able to collect, retain and order all the set of possible spends, essentially requiring a parallel network. The core of the system as it stands today is pretty simple (which was an explicit design goal to avoid getting forever distracted by the large design space), with a minimal implementation being relatively compact given all the Bitcoin context/design re-use. Also one cool trait of the way commitments are designed is that the Taro commitment impact the final derived taproot output key. As a result, potential Script extensions like TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transitions at the Bitcoin level, without Bitcoin explicitly needing to be aware of the Taro rules. In short, covenants can allow Bitcoin Script to bind Taro state transitions, without any of the logic bleeding over, as the covenant just checks for a certain output key, which is a function of the Taro commitment being present. > 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). Mechanically, with respect to the way the change/UTXOs work in the system, both are expressible: Dave can chose to merge them into a single UTXO (with the appropriate witnesses included for each of them), or Dave can keep them distinct in the asset tree. You're correct in that asset issuers may opt to issue assets in denominations vs allowing them to be fully divisible. Ultimately, the compatibility with the LN layer will be the primary way to keep asset histories compressed, without relying on another trust model, or relying on the incentive of an asset issuer to do a "re-genesis" which would effectively re-create assets in a supply-preserving manner (burn N units, then produce a new genesis outpoint for N units). Alternatively, implementations can also chose to utilize a checkpointing system similar to what some Bitcoin full node clients do today. > is that you end up with a linked transaction graph, just like in Bitcoin This is correct, the protocol doesn't claim to achieve better privacy guarantees than the base chain. However inheriting this transaction graph model imo makes it easier for existing Bitcoin developers to interact with the system, and all the data structures are very familiar tooling wise. However any privacy enhancing protocol used for on-chain top-level Bitcoin UTXOs can also be applied to Taro, so people can use things like coinswap and coinjoin, along with LN to shed prior coin lineages. > This implies the location of the Taro tree inside the taproot tree is not > fixed. What needs to be prevented here is that a taproot tree contains more > than one Taro tree, as that would enable the owner of the commitment to show > different histories to different people. Great observation, I patched a similar issue much earlier in the design process by strongly binding all signatures to a prevOut super-set (so the outpoint along with the unique key apth down into the tree), which prevents duplicating the asset across outputs, as signature verification would fail. In terms of achieving this level of binding within the Taro tree itself, I can think of three options: 1. Require the Taro commitment to be in the first/last position within the (fully sorted?) Tapscript tree, and also require its sibling to be the hash of some set string (all zeroes or w/e). We'd require the sibling to the empty as the tapscript hashes are sorted before hashing so you sort of lose that final ordering information. 2. Include the position of the Taro commitment within the tapscript tree within the sighash digest (basically the way the single input in the virtual transaction is created from the TLV structure). 3. Include the position of the Taro commitment within the tapscript tree as part of the message that's hashed to derive asset IDs. AFAICT, #1 resolves the issue entirely, #2 renders transfers outside of the canonical history invalid, and #2 minds hte asset ID to the initial position meaning you can track a canonical lineage from the very start. > Finally, let me conclude with two questions. Could you clarify the purpose of > the sparse merkle tree in your design? Sure, it does a few things: * Non-inclusion proofs so I can do things like prove to your I'm no longer committing to my 1-of-1 holographic beefzard card when we swap. * The key/tree structure means that the tree is history independent, meaning that if you and I insert the same things into the tree in a different order, we'll get the same root hash. This is useful for things like tracking all the issuance events for a given asset, or allowing two entities to sync their knowledge/history of a single asset, or a set of assets. * Each asset/script mapping to a unique location within the tree means it's easy to ensure uniqueness of certain items/commitments (not possible to commit to the same asset ID twice in the tree as an example). * The merkle-sum trait means I that validation is made simpler, as you just check that the input+output commitment sum to the same value, and I can also verify that if we're swapping, then you aren't committing to more units that exist (so I make sure I don't get an invalid split). > And the second question – when transferring Taro token ownership from one > Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do > you support the ability to "teleport" the tokens to an existing UTXO like how > RGB does it? If the latter, have you given consideration to timing issues > that might occur when someone sends tokens to an existing UTXO that > simultaneously happens to get spent by the owner? So for interactive transfers, the UTXOs generated as just the ones 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. Admittedly, I'm not familiar with how the RGB "teleport" technique works, I checked out some slide decks a while back, but they were mostly about all the new components they were creating and their milestone of 1 million lines of code. Can you point me to a coherent explanation of the technique? I'd love to compare/contrast so we can analyze the diff tradeoffs being made here. Thanks for an initial round of feedback/analysis, I'll be updating the draft over the next few days to better spell things out and particularly that commitment/sighash uniqueness trait. -- Laolu [1]: https://twitter.com/roasbeef/status/1330654936074371073?s=20&t=feV0kWAjJ6MTQlFm06tSxA [2]: https://twitter.com/roasbeef/status/1330692571736117249?s=20&t=feV0kWAjJ6MTQlFm06tSxA On Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen <rsom...@gmail.com> 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 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 better idea of how it > affects scaling. Also, the repeated sharing of history makes me skeptical > about the privacy this protocol may provide. If large amounts of history > moved through the hands of a large number of people, it wouldn't be very > private. > > There's a third third smaller issue I want to point out, which is easily > fixable and perhaps was just a typo. In your slides, you showed a > screenshot of a taproot tree containing the Taro tree as the third element > of four. This implies the location of the Taro tree inside the taproot tree > is not fixed. What needs to be prevented here is that a taproot tree > contains more than one Taro tree, as that would enable the owner of the > commitment to show different histories to different people. > > Finally, let me conclude with two questions. Could you clarify the purpose > of the sparse merkle tree in your design? I suppose you want to be able to > open a commitment and show it contains a certain asset without having to > reveal any of the other assets and simultaneously guarantee that you > haven't committed to the same asset twice (i.e. the SMT guarantees each > asset gets a specific location in the tree)? Or is there another reason? > > And the second question – when transferring Taro token ownership from one > Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do > you support the ability to "teleport" the tokens to an existing UTXO like > how RGB does it? If the latter, have you given consideration to timing > issues that might occur when someone sends tokens to an existing UTXO that > simultaneously happens to get spent by the owner? > > In any case, I hope this email was useful. Feel free to reach out if I can > clarify anything. > > Good luck with the protocol. > > Best regards, > Ruben > > On Tue, Apr 5, 2022 at 5:06 PM Olaoluwa Osuntokun via bitcoin-dev < > bitcoin-...@lists.linuxfoundation.org> wrote: > >> Hi y'all, >> >> I'm excited to publicly publish a new protocol I've been working on over >> the >> past few months: Taro. Taro is a Taproot Asset Representation Overlay >> which >> allows the issuance of normal and also collectible assets on the main >> Bitcoin >> chain. Taro uses the Taproot script tree to commit extra asset structured >> meta >> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree >> or >> MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a >> sparse >> merkle tree, enabling things like easily verifiable asset supply proofs >> and >> also efficient proofs of non existence (eg: you prove to me you're no >> longer >> committing to the 1-of-1 holographic beefzard card during our swap). Taro >> asset >> transfers are then embedded in a virtual/overlay transaction graph which >> uses a >> chain of asset witnesses to provably track the transfer of assets across >> taproot outputs. Taro also has a scripting system, which allows for >> programmatic unlocking/transfer of assets. In the first version, the >> scripting >> system is actually a recursive instance of the Bitcoin Script Taproot VM, >> meaning anything that can be expressed in the latest version of Script >> can be >> expressed in the Taro scripting system. Future versions of the scripting >> system >> can introduce new functionality on the Taro layer, like covenants or other >> updates. >> >> The Taro design also supports integration with the Lightning Network >> (BOLTs) as >> the scripting system can be used to emulate the existing HTLC structure, >> which >> allows for multi-hop transfers of Taro assets. Rather than modify the >> internal >> network, the protocol proposes to instead only recognize "assets at the >> edges", >> which means that only the sender+receiver actually need to know about and >> validate the assets. This deployment route means that we don't need to >> build up >> an entirely new network and liquidity for each asset. Instead, all asset >> transfers will utilize the Bitcoin backbone of the Lightning Network, >> which >> means that the internal routers just see Bitcoin transfers as normal, and >> don't >> even know about assets at the edges. As a result, increased demand for >> transfers of these assets as the edges (say like a USD stablecoin), which >> in >> will turn generate increased demand of LN capacity, result in more >> transfers, and >> also more routing revenue for the Bitcoin backbone nodes. >> >> The set of BIPs are a multi-part suite, with the following breakdown: >> * The main Taro protocol: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki >> * The MS-SMT structure: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki >> * The Taro VM: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki >> * The Taro address format: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki >> * The Taro Universe concept: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki >> * The Taro flat file proof format: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki >> >> Rather than post them all in line (as the text wouldn't fit in the >> allowed size >> limit), all the BIPs can be found above. >> >> -- Laolu >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-...@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev