Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
Hi Laolu, Yeah, that is definitely the main downside, as Ruben also mentioned: tokens are "burned" if they get sent to an already spent UTXO, and there is no way to block those transfers. And I do agree with your concern about losing the blockchain as the main synchronization point, that seems indeed to be a prerequisite for making the scheme safe in terms of re-orgs and asynchronicity. I do think the scheme itself is sound though (maybe not off-chain, see below): it prevents double spending and as long as the clients adhere to the "rule" of not sending to a spent UTXO you'll be fine (if not your tokens will be burned, the same way as if you don't satisfy the Taro script when spending). Thinking more about the examples you gave, I think you are right it won't easily be compatible with LN channels though: If you want to refill an existing channel with tokens, you need the channel counterparties to start signing new commitments that include spending the newly sent tokens. A problem arises however, if the channel is force-closed with a pre-existing commitment from before the token transfer took place. Since this commitment will be spending the funding UTXO, but not the new tokens, the tokens will be burned. And that seems to be harder to deal with (Eltoo style channels could be an avenue to explore, if one could override the broadcasted commitment). Tl;dr: I think you're right, the scheme is not compatible with LN. - Johan On Sat, Nov 5, 2022 at 1:36 AM Olaoluwa Osuntokun wrote: > > Hi Johan, > > I haven't really been able to find a precise technical explanation of the > "utxo teleport" scheme, but after thinking about your example use cases a > bit, I don't think the scheme is actually sound. Consider that the scheme > attempts to target transmitting "ownership" to a UTXO. However, by the time > that transaction hits the chain, the UTXO may no longer exist. At that > point, what happens to the asset? Is it burned? Can you retry it again? Does > it go back to the sender? > > As a concrete example, imagine I have a channel open, and give you an > address to "teleport" some additional assets to it. You take that addr, then > make a transaction to commit to the transfer. However, the block before you > commit to the transfer, my channel closes for w/e reason. As a result, when > the transaction committing to the UTXO (blinded or not), hits the chain, the > UTXO no longer exists. Alternatively, imagine the things happen in the > expected order, but then a re-org occurs, and my channel close is mined in a > block before the transfer. Ultimately, as a normal Bitcoin transaction isn't > used as a serialization point, the scheme seems to lack a necessary total > ordering to ensure safety. > > If we look at Taro's state transition model in contrast, everything is fully > bound to a single synchronization point: a normal Bitcoin transaction with > inputs consumed and outputs created. All transfers, just like Bitcoin > transactions, end up consuming assets from the set of inputs, and > re-creating them with a different distribution with the set of outputs. As a > result, Taro transfers inherit the same re-org safety traits as regular > Bitcoin transactions. It also isn't possible to send to something that won't > ultimately exist, as sends create new outputs just like Bitcoin > transactions. > > Taro's state transition model also means anything you can do today with > Bitcoin/LN also apply. As an example, it would be possible for you to > withdrawn from your exchange into a Loop In address (on chain to off chain > swap), and have everything work as expected, with you topping off your > channel. Stuff like splicing, and other interactive transaction construction > schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work. > > Ignoring the ordering issue I mentioned above, I don't think this is a great > model for anchoring assets in channels either. With Taro, when you make the > channel, you know how many assets are committed since they're all committed > to in the funding output when the channel is created. However, let's say we > do teleporting instead: at which point would we recognize the new asset > "deposits"? What if we close before a pending deposits confirms, how can one > regain those funds? Once again you lose the serialization of events/actions > the blockchain provides. I think you'd also run into similar issues when you > start to think about how these would even be advertised on a hypothetical > gossip network. > > I think one other drawback of the teleport model iiuc is that: it either > requires an OP_RETURN, or additional out of band synchronization to complete > the transfer. Since it needs to commit to w/e hash description of the > teleport, it either needs to use an OP_RETURN (so the receiver can see the > on chain action), or the sender needs to contact the receiver to initiate > the resolution of the transfer (details committed to in a change addr or > w/e). > > With Taro,
Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
Hi Johan, I haven't really been able to find a precise technical explanation of the "utxo teleport" scheme, but after thinking about your example use cases a bit, I don't think the scheme is actually sound. Consider that the scheme attempts to target transmitting "ownership" to a UTXO. However, by the time that transaction hits the chain, the UTXO may no longer exist. At that point, what happens to the asset? Is it burned? Can you retry it again? Does it go back to the sender? As a concrete example, imagine I have a channel open, and give you an address to "teleport" some additional assets to it. You take that addr, then make a transaction to commit to the transfer. However, the block before you commit to the transfer, my channel closes for w/e reason. As a result, when the transaction committing to the UTXO (blinded or not), hits the chain, the UTXO no longer exists. Alternatively, imagine the things happen in the expected order, but then a re-org occurs, and my channel close is mined in a block before the transfer. Ultimately, as a normal Bitcoin transaction isn't used as a serialization point, the scheme seems to lack a necessary total ordering to ensure safety. If we look at Taro's state transition model in contrast, everything is fully bound to a single synchronization point: a normal Bitcoin transaction with inputs consumed and outputs created. All transfers, just like Bitcoin transactions, end up consuming assets from the set of inputs, and re-creating them with a different distribution with the set of outputs. As a result, Taro transfers inherit the same re-org safety traits as regular Bitcoin transactions. It also isn't possible to send to something that won't ultimately exist, as sends create new outputs just like Bitcoin transactions. Taro's state transition model also means anything you can do today with Bitcoin/LN also apply. As an example, it would be possible for you to withdrawn from your exchange into a Loop In address (on chain to off chain swap), and have everything work as expected, with you topping off your channel. Stuff like splicing, and other interactive transaction construction schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work. Ignoring the ordering issue I mentioned above, I don't think this is a great model for anchoring assets in channels either. With Taro, when you make the channel, you know how many assets are committed since they're all committed to in the funding output when the channel is created. However, let's say we do teleporting instead: at which point would we recognize the new asset "deposits"? What if we close before a pending deposits confirms, how can one regain those funds? Once again you lose the serialization of events/actions the blockchain provides. I think you'd also run into similar issues when you start to think about how these would even be advertised on a hypothetical gossip network. I think one other drawback of the teleport model iiuc is that: it either requires an OP_RETURN, or additional out of band synchronization to complete the transfer. Since it needs to commit to w/e hash description of the teleport, it either needs to use an OP_RETURN (so the receiver can see the on chain action), or the sender needs to contact the receiver to initiate the resolution of the transfer (details committed to in a change addr or w/e). With Taro, sending to an address creates an on-chain taproot output just like sending to a P2TR address. The creation of the output directly creates the new asset anchor/output as well, which allows the receiver to look for that address on chain just like a normal on chain transaction. To 3rd party observers, it just looks like a normal P2TR transfer. In order to finalize the receipt of the asset, the receiver needs to obtain the relevant provenance proofs, which can be obtained from a multi-verse gRPC/HTTP service keyed by the input outpoint and output index. In short, the send process is fully async, with the sender and receiver using the blockchain itself as a synchronization point like a normal Bitcoin wallet. -- Laolu ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
Hi, I wanted to chime in on the "teleport" feature explained by Ruben, as I think exploring something similar for Taro could be super useful in an LN setting. In today's Taro, to transfer tokens you have to spend a UTXO, and present a proof showing that there are tokens committed to in the output you are spending. Let's say this UTXO is 'utxo:0'. In contrast, to spend teleported tokens, you would still spend utxo:0, but you would only have to present a proof that _some txout_ on-chain have committed tokens to utxo:0. As Ruben points out, this makes it possible to send tokens to an already spent TXO, essentially burning the tokens. However, it opens up some exciting possibilities IMO. You can in essence use this to "re-fill" UTXOs with tokens, which is very interesting for LN channels: - You could "add" tokens to your already open channels. The only thing needed is for the channel participants to be presented the proof that tokens were sent to the funding output, and they can update their commitment transaction to start spending these tokens. - You can "top-up" all your channels in a single on-chain tx. Since a single output can commit tokens to several UTXOs, you could with a single on-chain transaction add tokens to many channels without opening and closing them. RGB also has the ability to "blind" the UTXO that tokens get teleported to, hiding the recipient UTXO. This is cool, since I could withdraw tokens from an exchange directly into my LN channel, without revealing my channel UTXO. I found the explanation of the teleport feature in this blog post pretty good: https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059 - Johan On Sun, Apr 10, 2022 at 6:52 PM Ruben Somsen wrote: > Hi Laolu, > > >happy to hear that someone was actually able to extract enough details > from the RGB devs/docs to be able to analyze it properly > > Actually, even though I eventually puzzled everything together, this did > not go well for me either. There is a ton of documentation, but it's a maze > of unhelpful details, and none of it clearly maps out the fundamental > design. I was also disappointed by the poor response I received when asking > questions, and I ended up getting chastised for helping others understand > it and pointing out potential flaws[1][2][3].Given my experience, I think > the project is not in great shape, so the decision to rebuild from scratch > seems right to me. > > That said, in my opinion the above should not factor into the decision of > whether RGB should be credited in the Taro documentation. The design > clearly precedes (and seems to have inspired) Taro, so in my opinion this > should be acknowledged. Also, the people that are responsible for the > current shape of RGB aren't the people who originated the idea, so it would > not be fair to the originators either (Peter Todd, Alekos Filini, Giacomo > Zucco). > > >assets can be burnt if a user doesn't supply a valid witness > > I am in agreement with what you said, but it is not clear to me whether we > are on the same page. What I tried to say was that it does not make sense > to build scripting support into Taro, because you can't actually do > anything interesting with it due to this limitation. The only type of smart > contract you can build is one where you limit what the owner (as defined by > Bitcoin's script) can do with their own Taro tokens, or else he will burn > them – not very useful. Anything involving a conditional transfer of > ownership to either A or B (i.e. any meaningful type of script) won't work. > Do you see what I mean, or should I elaborate further? > > >TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transitions > at the Bitcoin level, without Bitcoin explicitly needing to be aware > > That is conceptually quite interesting. So theoretically you could get > Bitcoin covenants to enforce certain spending conditions on Taro assets. > Not sure how practical that ends up being, but intriguing to consider. > > >asset issuer to do a "re-genesis" > > Yes, RGB suggested the same thing, and this can work under some > circumstances, but note that this won't help for tokens that aim to have a > publicly audited supply, as the proof that a token was legitimately > re-issued is the history of the previous token (so you'd actually be making > things worse, as now everyone has to verify it). And of course the idea > also requires the issuer to be active, which may not always be the case. > > >I'm not familiar with how the RGB "teleport" technique works [...] Can > you point me to a coherent explanation of the technique > > To my knowledge no good explanation exists. "Teleporting" is just what I > thought was a good way of describing it. Basically, in your design when > Alice wants to send a Taro token to Bob, Alice has to spend her own output, > make a new output for Bob, and make a change output for herself. Inside the > Taro tree you'll then point to the index of Bob's output in order to
Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
Hi Hiroki, (inserting the bitcoin-dev mailing list as this question is mainly concerning on-chain interaction) Thanks for taking the time to really dig into things! > When trying to verify the provenance of a given UTXO, it is necessary to > verify the state transitions of all transaction graphs without gaps from > the genesis transaction of the asset to the current location > It is necessary to prove and verify that “the UTXO has not changed” at > that point. Correct! > As far as I can see, the specs don't mention it. You're correct that today the main BIP draft focuses mainly on transfers [1] to specify how exactly an asset moves from one output to another. The requirement that a "no-op" state transition also be created/verified is an implicit assumption in the current spec that we aim to remedy. The current alpha code [2] is a bit ahead of the spec, but we aim to start to catch up the spec, and also begin to add test vectors now that we have a working implementation. > The proofs for directly proving that a UTXO has not changed are its > inclusion proof in the input asset tree and its inclusion and > non-inclusion proofs in each of the output asset trees Correct, the set of inclusion and non-inclusion proofs necessary for a valid state transition are currently documented in `bip-taro-proof-file.md` [3]. We've also made a few updates to the proof file format to properly include a field for the inclusion proof of a split asset's _root_ asset. This allows verifiers to properly verify the authenticity of the split (root is in the transaction, uniquely, which commits to the split, which has a proof anchored in that spit root). > Instead, it's better to set a constraint that no part of the asset tree > except the explicitly changed UTXOs should change, and verify that. Interesting, so rather than present/maintain a distinct state transition for each asset unaffected, you propose that instead we present a _single_ proof for all non-modified assets that shows that a sub-tree/branch is unchanged? That's a very cool idea. Generally we have a lot of low hanging fruits re optimizing the proof file format itself. As an example, all assets in a tree will share the same Bitcoin-level proof prefix (merkle proof and block header of the anchor transaction), but the spec/implementation will currently duplicate those values several times over for each asset. If we go down another level, then the main inclusion proof for an asset ID tree is also duplicated for each asset sharing that asset ID. Restating things a bit: right now proofs are oriented from the PoV of an asset leaf in question. Instead, if we zoom out a bit and orient them at the _taproot output_ level, then we can remove a lot of redundant data in the current proof format, then sort of "prune" the output level proof to generate a proof for a single leaf. -- Laolu [1]: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki#asset-transfers [2]: https://github.com/lightninglabs/taro [3]: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki#specification On Fri, Oct 7, 2022 at 2:33 AM Hiroki Gondo wrote: > Hi Laolu, > > I've read Taro's specs, but I'm afraid there's not enough verification of > the provenance of the asset UTXOs. > > When trying to verify the provenance of a given UTXO, it is necessary to > verify the state transitions of all transaction graphs without gaps from > the genesis transaction of the asset to the current location. At some point > in the transaction, the target UTXO itself may not change (only changes to > other assets or other UTXOs in the asset tree). It is necessary to prove > and verify that “the UTXO has not changed” at that point. As far as I can > see, the specs don't mention it. > > Without this validation, asset inflation (double spending) is possible. In > a transaction, there is a UTXO in the input asset tree. If this UTXO does > not change in this transaction, it will remain in the output asset tree. > However, if a full copy of this UTXO is illicitly created in the asset tree > of another output, the asset will be inflated (even duplicating the lowest > MS-SMT entirely). Both UTXOs will arbitrarily claim to be the same as the > input UTXO. > > The proofs for directly proving that a UTXO has not changed are its > inclusion proof in the input asset tree and its inclusion and non-inclusion > proofs in each of the output asset trees. However, generating these proofs > for every unchanging UTXO present in the input asset tree when a > transaction occurs may not be very practical. Instead, it's better to set a > constraint that no part of the asset tree except the explicitly changed > UTXOs should change, and verify that. > > Please let me know if I'm wrong or have overlooked any specs. Also, let me > know if there's anything about this that hasn't been mentioned in the specs > yet. > > – > Hiroki Gondo > > > 2022年4月6日(水) 0:06 Olaoluwa Osuntokun : > >> Hi y'all, >> >> I'm excited t
Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
(this might be a double post as I ran into the size limit) Hi Alex, Thanks for taking a look at things! > 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? I considered other approaches, but by relying on the existing taproot commitment structure/derivation, Taro implementations are able to re-use surrounding code/libraries, making a core implementation more compact. Committing into the tapscript tree is also simpler than signature tweaks. One nice trait about using the tapscript tree is that from a wallet's perceptive, Taro just wants a particular opaque hash to be included in the final tapscript tree. As a result, the wallet doesn't need to modify the way they sign, or do key derivations or anything. In addition, using the tapscript tree lets us separate the Bitcoin layer from the Taro layer as far as scripts, and also enables easily verification of any sort of Script mirroring between the layers that may be required for certain applications. > This reminds me a lot of single-use-seals[3]. Is that the right way to > think about what's going on here? Yes a similar construct is used. I personally don't really like the single-use-seals terminology, as I find it somewhat obtuse and trying to bind the mechanics to the analogy/metaphor just makes it harder for people to understand what's going on. > 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). So the provide a few different types of functionality: * A way to bootstrap genesis output provenance by maintaining a Universe which is just the set of asset issuance transactions (the Universe MS-SMT is keyed by a prevOut at the lowest level). This can be done for several assets. * A way to collect+index a more complete view of the set of transfers related to assets. This can serve the basis for things like a block explorer for a single or several assets. Since the data structure is history independent, multiple explorers can publish their root hash which makes it easy to check that they have the same data, and a bisection protocol can be used to sync up distinct universe/multiverse instances. * A way to allow aggregation of transfers tied to a single to level UTXO chain, which would likely be used in cases like games where the actual game needs other servers or closed source functionality, but the game publisher wants the users to be able to prove ownership and also trade in game asset. This can be maintained by a single party, or a threshold/federation. The parties can't include invalid state transitions or proofs (can't forge the proper signature, etc). > - 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. Yep! I described a sketch of something like that using TLVU in my prior reply to Rubin. At a high level, since Taro affect the tapscript root hash, which affects the output key, by requiring a certain output key, or swapping out the leaf elements, a covenant can further bind Taro rules without needing to explicitly do validation/execution in Bitcoin script itself. > My first thought was to have the "carrier utxo" for a taro asset be really > small, like dust + some buffer. Hmm, can you describe this in more detail? Do you mean an _extra_ UTXO, or just mapping the Taro conditions as much as possible to the top-level Bitcoin scripts? > - was this originally named CMYK? Maybe ;), a few versions were floating around before I published the current draft, so some prior artifacts may still be floating around. Will do another sweep to clean up anything else that was lingering. -- Laolu ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 coul
