* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay @ 2022-04-05 20:23 vjudeu 2022-04-06 0:43 ` ZmnSCPxj 0 siblings, 1 reply; 12+ messages in thread From: vjudeu @ 2022-04-05 20:23 UTC (permalink / raw) To: bitcoin-dev, laolu32 When I see more and more proposals like this, where things are commited to Taproot outputs, then I think we should start designing "miner-based commitments". If someone is going to make a Bitcoin transaction and add a commitment for zero cost, just by tweaking some Taproot public key, then it is a benefit for the network, because then it is possible to get more things with no additional bytes. Instead of doing "transaction-only", people can do "transaction+commitment" for the same cost, that use case is positive. But if someone is going to make a Bitcoin transaction only to commit things, where in other case that person would make no transaction at all, then I think we should have some mechanism for "miner-based commitments" that would allow making commitments in a standardized way. We always have one coinbase transaction for each block, it is consensus rule. So, by tweaking single public key in the coinbase transaction, it is possible to fit all commitments in one tweaked key, and even make it logarithmic by forming a tree of commitments. I think we cannot control user-based commitments, but maybe we should standardize miner-based commitments, for example to have a sorted merkle tree of commitments. Then, it would be possible to check if some commitment is a part of that tree or not (if it is always sorted, then it is present at some specified position or not, so by forming SPV-proof we can quickly prove, if some commitment is or is not a part of some miner Taproot commitment). On 2022-04-05 15:06:03 user Olaoluwa Osuntokun <laolu32@gmail•com> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-05 20:23 [bitcoin-dev] Taro: A Taproot Asset Representation Overlay vjudeu @ 2022-04-06 0:43 ` ZmnSCPxj 0 siblings, 0 replies; 12+ messages in thread From: ZmnSCPxj @ 2022-04-06 0:43 UTC (permalink / raw) To: vjudeu, Bitcoin Protocol Discussion Good morning vjudeu, > When I see more and more proposals like this, where things are commited to Taproot outputs, then I think we should start designing "miner-based commitments". If someone is going to make a Bitcoin transaction and add a commitment for zero cost, just by tweaking some Taproot public key, then it is a benefit for the network, because then it is possible to get more things with no additional bytes. Instead of doing "transaction-only", people can do "transaction+commitment" for the same cost, that use case is positive. > > But if someone is going to make a Bitcoin transaction only to commit things, where in other case that person would make no transaction at all, then I think we should have some mechanism for "miner-based commitments" that would allow making commitments in a standardized way. We always have one coinbase transaction for each block, it is consensus rule. So, by tweaking single public key in the coinbase transaction, it is possible to fit all commitments in one tweaked key, and even make it logarithmic by forming a tree of commitments. > > I think we cannot control user-based commitments, but maybe we should standardize miner-based commitments, for example to have a sorted merkle tree of commitments. Then, it would be possible to check if some commitment is a part of that tree or not (if it is always sorted, then it is present at some specified position or not, so by forming SPV-proof we can quickly prove, if some commitment is or is not a part of some miner Taproot commitment). You might consider implementing `OP_BRIBE` from Drivechains, then. Note that if you *want* to have some data committed on the blockchain, you *have to* pay for the privilege of doing so --- miners are not obligated to put a commitment to *your* data on the coinbase for free. Thus, any miner-based commitment needs to have a mechanism to offer payments to miners to include your commitment. You might as well just use a transaction, and not tell miners that you want to commit data using some tweak of the public key (because the miners might then be induced to censor such commitments). In short: there is no such thing as "other case that person would make no transcation at all", because you have to somehow bribe miners to include the commitment to your data, and you might as well use existing mechanisms (transactions that implicitly pay fees) for your data commitment, and get better censorship-resistance and privacy. Nothing really prevents any transaction-based scheme from having multiple users that aggregate their data (losing privacy but aggregating their fees) to make a sum commitment and just make a single transaction that pays for the privilege of committing to the sum commitment. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
@ 2022-04-11 0:30 Bram Cohen
2022-04-11 18:21 ` Olaoluwa Osuntokun
0 siblings, 1 reply; 12+ messages in thread
From: Bram Cohen @ 2022-04-11 0:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
From: Olaoluwa Osuntokun <laolu32@gmail•com>
>
> > 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.
>
The TARO set of tradeoffs is fairly coherent but is subject to certain
limitations (modulo my understanding of it being off):
The witnesses for transactions need to be put into Bitcoin transactions
even though the Bitcoin layer doesn't understand them
There needs to be a constraint on Taro transactions which is understood by
the Bitcoin layer (which often/usually happens naturally because there's a
user signature but sometimes doesn't. It's a limitation)
Multiple Taro coins can't consolidate their value into a single output
because they only support a single linear history
Taro issuance is limited to a single event rather than potentially multiple
events over time subject to special per-asset rules.
This seems like a fairly logical approach (although my understanding of the
limitations/tradeoffs could be wrong, especially with regards to
consolidation). There's nothing wrong with a system having well documented
limitations, but I am puzzled by the announcement saying Taro assets are
'analogous with' colored coins. Taro assets are straightforwardly and
unambiguously colored coins and that isn't something to be ashamed of.
[-- Attachment #2: Type: text/html, Size: 3655 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-11 0:30 Bram Cohen @ 2022-04-11 18:21 ` Olaoluwa Osuntokun 2022-04-11 21:29 ` Bram Cohen 0 siblings, 1 reply; 12+ messages in thread From: Olaoluwa Osuntokun @ 2022-04-11 18:21 UTC (permalink / raw) To: Bram Cohen, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5104 bytes --] Hi Bram, > The witnesses for transactions need to be put into Bitcoin transactions > even though the Bitcoin layer doesn't understand them Is this related to Ruben's comment about invalid state transitions (published in the base chain) leading to burned assets? In the past, I've considered using the existing annex field in taproot transactions to implement partial reveal of certain data. However, today bitcoind treats annex usage as non-standard, so those transactions may be harder to relay. IMO this is a great place to add minimal extra data, as it doesn't bleed over into the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures also include this field in the sighash, the sigs serve to further authenticate this data. Future op codes that allow Scripts to push annex data onto the stack could also be used to further bind higher level protocols while still allowing the base Bitcoin consensus rules to not have to be explicitly aware of them. > Taro issuance is limited to a single event rather than potentially > multiple events over time subject to special per-asset rules. There's a provision in the protocol that lets a party issuing assets to specify a special public key which is then tweaked with the genesis outpoint, similar to the way the asset IDs are generated. If this key is specified, then future issuance, if signed off by that key, will serve to associate assets of discrete IDs under a single identifier. This feature allows assets issued in multiple tranches to be fungible with one another. > but I am puzzled by the announcement saying Taro assets are 'analogous > with' colored coins. Taro assets are straightforwardly and unambiguously > colored coins and that isn't something to be ashamed of. We've shied away from using the "colored coins' terminology as at this point in the game it's pretty dated: new developers that joined in the last 3 years or so have likely never heard of that term. Explaining the term also requires one to define "coin coloring", and what that actually means, etc, etc. IMO it's simpler to just use the familiar and widely used asset issuance/minting terminology. -- Laolu On Sun, Apr 10, 2022 at 9:10 PM Bram Cohen via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > From: Olaoluwa Osuntokun <laolu32@gmail•com> > >> >> > 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. >> > > The TARO set of tradeoffs is fairly coherent but is subject to certain > limitations (modulo my understanding of it being off): > > The witnesses for transactions need to be put into Bitcoin transactions > even though the Bitcoin layer doesn't understand them > > There needs to be a constraint on Taro transactions which is understood by > the Bitcoin layer (which often/usually happens naturally because there's a > user signature but sometimes doesn't. It's a limitation) > > Multiple Taro coins can't consolidate their value into a single output > because they only support a single linear history > > Taro issuance is limited to a single event rather than potentially > multiple events over time subject to special per-asset rules. > > This seems like a fairly logical approach (although my understanding of > the limitations/tradeoffs could be wrong, especially with regards to > consolidation). There's nothing wrong with a system having well documented > limitations, but I am puzzled by the announcement saying Taro assets are > 'analogous with' colored coins. Taro assets are straightforwardly and > unambiguously colored coins and that isn't something to be ashamed of. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6778 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-11 18:21 ` Olaoluwa Osuntokun @ 2022-04-11 21:29 ` Bram Cohen 0 siblings, 0 replies; 12+ messages in thread From: Bram Cohen @ 2022-04-11 21:29 UTC (permalink / raw) To: Olaoluwa Osuntokun; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3266 bytes --] On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa Osuntokun <laolu32@gmail•com> wrote: > Hi Bram, > > > The witnesses for transactions need to be put into Bitcoin transactions > > even though the Bitcoin layer doesn't understand them > > Is this related to Ruben's comment about invalid state transitions > (published in the base chain) leading to burned assets? > Yes, or at least the concern that a valid transaction could have its required witness data not posted to the chain and be effectively bricked. > In the past, I've > considered using the existing annex field in taproot transactions to > implement partial reveal of certain data. However, today bitcoind treats > annex usage as non-standard, so those transactions may be harder to relay. > IMO this is a great place to add minimal extra data, as it doesn't bleed > over into > the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures > also include this field in the sighash, the sigs serve to further > authenticate this data. > That leads to a bit of a philosophical question: Is the annex reserved for possible future Bitcoin script soft forks, or is it free to use for whatever with confidence there won't be a future collision? But that might not matter, because if the purpose is to force the extra witness information to be published it has to be in something signed in the transaction, and barring a check sig from stack that probably means it has to be shoved into the transaction somewhere. > > Taro issuance is limited to a single event rather than potentially > > multiple events over time subject to special per-asset rules. > > There's a provision in the protocol that lets a party issuing assets to > specify a special public key which is then tweaked with the genesis > outpoint, similar to the way the asset IDs are generated. If this key is > specified, then future issuance, if signed off by that key, will serve to > associate assets of discrete IDs under a single identifier. This feature > allows assets issued in multiple tranches to be fungible with one another. > Ah I see. That's still a fairly bespoke set of functionality instead of allowing an arbitrary script to be used for the issuance (but that again runs into Bitcoin script being fairly limited in its functionality). > > > but I am puzzled by the announcement saying Taro assets are 'analogous > > with' colored coins. Taro assets are straightforwardly and unambiguously > > colored coins and that isn't something to be ashamed of. > > We've shied away from using the "colored coins' terminology as at this > point > in the game it's pretty dated: new developers that joined in the last 3 > years or so have likely never heard of that term. Explaining the term also > requires one to define "coin coloring", and what that actually means, etc, > etc. IMO it's simpler to just use the familiar and widely used asset > issuance/minting terminology. > People mostly haven't heard of colored coins in a while because everything has been based on ERC-20 style tokens, which are truly horrid. Coloring is a meaningful technical term which means something good, although unfortunately the term 'colored' is a bit loaded in different ways around the world so it's best to keep it in the technical docs. [-- Attachment #2: Type: text/html, Size: 4369 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* [bitcoin-dev] Taro: A Taproot Asset Representation Overlay @ 2022-04-05 15:06 Olaoluwa Osuntokun 2022-04-07 17:14 ` Ruben Somsen 0 siblings, 1 reply; 12+ messages in thread From: Olaoluwa Osuntokun @ 2022-04-05 15:06 UTC (permalink / raw) To: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev, lightning-dev [-- Attachment #1: Type: text/plain, Size: 3111 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 3837 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-05 15:06 Olaoluwa Osuntokun @ 2022-04-07 17:14 ` Ruben Somsen 2022-04-08 17:48 ` Olaoluwa Osuntokun 0 siblings, 1 reply; 12+ messages in thread From: Ruben Somsen @ 2022-04-07 17:14 UTC (permalink / raw) To: Olaoluwa Osuntokun, Bitcoin Protocol Discussion; +Cc: lightning-dev [-- Attachment #1: Type: text/plain, Size: 10505 bytes --] 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-dev@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-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 12101 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-07 17:14 ` Ruben Somsen @ 2022-04-08 17:48 ` Olaoluwa Osuntokun 2022-04-10 16:51 ` Ruben Somsen 2022-04-16 2:43 ` Olaoluwa Osuntokun 0 siblings, 2 replies; 12+ messages in thread From: Olaoluwa Osuntokun @ 2022-04-08 17:48 UTC (permalink / raw) To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8961 bytes --] (this might be a double post as it ran into the size limit) 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 [-- Attachment #2: Type: text/html, Size: 9738 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-08 17:48 ` Olaoluwa Osuntokun @ 2022-04-10 16:51 ` Ruben Somsen 2022-04-11 19:51 ` Olaoluwa Osuntokun 2022-04-16 2:43 ` Olaoluwa Osuntokun 1 sibling, 1 reply; 12+ messages in thread From: Ruben Somsen @ 2022-04-10 16:51 UTC (permalink / raw) To: Olaoluwa Osuntokun, Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 13830 bytes --] 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 assign the tokens to his new output. Instead of pointing to the index, you could point to the outpoint (txid, index) of an existing UTXO owned by Bob, thus "teleporting" the Taro tokens to this UTXO. This saves on-chain space, as now you don't have to create a new output for Bob (but now you have to ensure Bob doesn't spend from this output while you're simultaneously sending tokens to it, as I mentioned in my previous post, as this would destroy the tokens). The above also reminds me of another potential issue which you need to be aware of, if you're not already. Similar to my comment about how the location of the Taro tree inside the taproot tree needs to be deterministic for the verifier, the output in which you place the Taro tree also needs to be. If it's not, then you can commit to a different Taro tree in each output of the transaction, allowing you to secretly fork the history. Hope this helps. Cheers, Ruben [1] https://twitter.com/SomsenRuben/status/1397267261619064836 [2] https://twitter.com/SomsenRuben/status/1397559406565462017 [3] https://twitter.com/afilini/status/1397484341236797441 On Fri, Apr 8, 2022 at 7:48 PM Olaoluwa Osuntokun <laolu32@gmail•com> wrote: > (this might be a double post as it ran into the size limit) > > 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 > [-- Attachment #2: Type: text/html, Size: 16204 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-10 16:51 ` Ruben Somsen @ 2022-04-11 19:51 ` Olaoluwa Osuntokun 2022-04-15 13:14 ` Ruben Somsen 0 siblings, 1 reply; 12+ messages in thread From: Olaoluwa Osuntokun @ 2022-04-11 19:51 UTC (permalink / raw) To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 4786 bytes --] Hi Ruben, > 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). Sure I have no problems acknowledging them in the current BIP draft. Both the protocols build off of ideas re client-side-validation, but then end up exploring different parts of the large design space. Peter Todd is already there, but I can add the others you've listed. I might even just expand that section into a longer "Related Work" section along the way. > 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. can do with their own Taro tokens, or else he > will burn them – not very useful I agree that the usage will be somewhat context specific, and dependent on the security properties one is after. In the current purposefully simplified version, it's correct that ignoring the rules leads to assets being burnt, but in most cases imo that's a sufficient enough incentive to maintain and validate the relevant set of witnesses. I was thinking about the scripting layer a bit over the weekend, and came up with a "issuance covenant" design sketch that may or may not be useful. At a high level, lets say we extend the system to allow a specified (so a new asset type) or generalized script to be validated when an asset issuance transaction is being validated. If we add some new domain specific covenant op codes at the Taro level, then we'd be able to validate issuance events like: * "Issuing N units of this assets can only be done if 1.5*N units of BTC are present in the nth output of the minting transaction. In addition, the output created must commit to a NUMs point for the internal key, meaning that only a script path is possible. The script paths must be revealed, with the only acceptable unlocking leaf being a time lock of 9 months". I don't fully have a concrete protocol that would use something like that, but that was an attempt to express certain collateralization requirements for issuing certain assets. Verifiers would only recognize that asset if the issuance covenant script passes, and (perhaps) the absolute timelock on those coins hasn't expired yet. This seems like a useful primitive for creating assets that are somehow backed by on-chain BTC collateralization. However this is just a design sketch that needs to answer questions like: * are the assets still valid after that timeout period, or are they considered to be burnt? * assuming that the "asset key family" (used to authorize issuance of related assets) are jointly owned, and maintained in a canonical Universe, then would it be possible for 3rd parties to verify the level of collateralization on-chain, with the join parties maintaining the pool of collateralized assets accordingly? * continuing with the above, is it feasible to use a DLC script within one of these fixed tapscript leaves to allow more collateral to be added/removed from the pool backing those assets? I think it's too early to conclude that the scripting layer isn't useful. Over time I plan to add more concrete ideas like the above to the section tracking the types of applications that can be built on Taro. > 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. Exactly! Exactly how practical it ends up being would depend on the types of covenants deployed in the future. With something like a TLUV and OP_CAT (as they're sufficiently generalized vs adding op codes to very the proofs) a Script would be able to re-create the set of commitments to restrict the set of outputs that can be created after spending. One would use OP_CAT to handle re-creating the taro asset root, and TLUV (or something similar) to handle the Bitcoin tapscript part (swap out leaf index 0 where the taro commitment is, etc). > The above also reminds me of another potential issue which you need to be > aware of, if you're not already. Similar to my comment about how the > location of the Taro tree inside the taproot tree needs to be > deterministic for the verifier, the output in which you place the Taro > tree also needs to be Yep, the location needs to be fully specified which includes factoring the output index as well. A simple way to restrict this would just to say it's always the first output. Otherwise, you could lift the output index into the asset ID calculation. -- Laolu [-- Attachment #2: Type: text/html, Size: 5154 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-11 19:51 ` Olaoluwa Osuntokun @ 2022-04-15 13:14 ` Ruben Somsen 0 siblings, 0 replies; 12+ messages in thread From: Ruben Somsen @ 2022-04-15 13:14 UTC (permalink / raw) To: Olaoluwa Osuntokun; +Cc: Bitcoin Protocol Discussion, lightning-dev [-- Attachment #1: Type: text/plain, Size: 7097 bytes --] Hi Laolu, > ignoring the rules leads to assets being burnt, but in most cases imo that's a sufficient enough incentive to maintain and validate the relevant set of witnesses I agree it is sufficient, but only because using Bitcoin script without an additional scripting language inside of Taro is already sufficient. Perhaps you could show me a concrete example where you think replicating Bitcoin's scripting capabilities inside Taro can be useful, so I can show you where I think it fails. > came up with a "issuance covenant" design sketch that may or may not be useful To summarize my view from my first post, I basically think there are two broad exceptions to the "can't do scripting" rule: 1. Self-encumbrance: you have to use the token according to the rules, else the token becomes burned/invalid. The example you're giving here can be said to fall under this category. The usefulness of this is extremely narrow, and merely replicating Bitcoin's script inside of Taro is certainly not sufficient to achieve it. 2. On-chain validation: instead of keeping the satisfaction of the script off-chain, you publish it on-chain in the Bitcoin blockchain. This works, but breaks a fundamental design goal of Taro/RGB (remaining off-chain), and adds significant complexity. These two points lead me to my conclusion that off-chain validation protocols (to rule out the exception in point 2) can't do any meaningful (to rule out the exception in point 1) scripting. This doesn't mean you can't still add some scripting to facilitate certain use cases that fall under the two exceptions, but a regular scripting language for on-chain payments such as Bitcoin's is not going to cut it (at least not without significant changes). Personally I'd be inclined to leave out the scripting language altogether (as the encumbrance of Bitcoin UTXOs is sufficient in most cases), unless you have a very specific and compelling use case in mind that justify the complexity. Cheers, Ruben On Mon, Apr 11, 2022 at 9:52 PM Olaoluwa Osuntokun <laolu32@gmail•com> wrote: > Hi Ruben, > > > 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). > > Sure I have no problems acknowledging them in the current BIP draft. Both > the protocols build off of ideas re client-side-validation, but then end up > exploring different parts of the large design space. Peter Todd is already > there, but I can add the others you've listed. I might even just expand > that > section into a longer "Related Work" section along the way. > > > 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. can do with their own Taro tokens, or else he > > will burn them – not very useful > > I agree that the usage will be somewhat context specific, and dependent on > the security properties one is after. In the current purposefully > simplified > version, it's correct that ignoring the rules leads to assets being burnt, > but in most cases imo that's a sufficient enough incentive to maintain and > validate the relevant set of witnesses. > > I was thinking about the scripting layer a bit over the weekend, and came > up > with a "issuance covenant" design sketch that may or may not be useful. At > a > high level, lets say we extend the system to allow a specified (so a new > asset type) or generalized script to be validated when an asset issuance > transaction is being validated. If we add some new domain specific covenant > op codes at the Taro level, then we'd be able to validate issuance events > like: > > * "Issuing N units of this assets can only be done if 1.5*N units of BTC > are present in the nth output of the minting transaction. In addition, > the output created must commit to a NUMs point for the internal key, > meaning that only a script path is possible. The script paths must be > revealed, with the only acceptable unlocking leaf being a time lock of > 9 > months". > > I don't fully have a concrete protocol that would use something like that, > but that was an attempt to express certain collateralization requirements > for issuing certain assets. Verifiers would only recognize that asset if > the > issuance covenant script passes, and (perhaps) the absolute timelock on > those coins hasn't expired yet. This seems like a useful primitive for > creating assets that are somehow backed by on-chain BTC collateralization. > However this is just a design sketch that needs to answer questions like: > > * are the assets still valid after that timeout period, or are they > considered to be burnt? > > * assuming that the "asset key family" (used to authorize issuance of > related assets) are jointly owned, and maintained in a canonical > Universe, then would it be possible for 3rd parties to verify the level > of collateralization on-chain, with the join parties maintaining the > pool of collateralized assets accordingly? > > * continuing with the above, is it feasible to use a DLC script within > one > of these fixed tapscript leaves to allow more collateral to be > added/removed from the pool backing those assets? > > I think it's too early to conclude that the scripting layer isn't useful. > Over time I plan to add more concrete ideas like the above to the section > tracking the types of applications that can be built on Taro. > > > 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. > > Exactly! Exactly how practical it ends up being would depend on the types > of > covenants deployed in the future. With something like a TLUV and OP_CAT (as > they're sufficiently generalized vs adding op codes to very the proofs) a > Script would be able to re-create the set of commitments to restrict the > set > of outputs that can be created after spending. One would use OP_CAT to > handle re-creating the taro asset root, and TLUV (or something similar) to > handle the Bitcoin tapscript part (swap out leaf index 0 where the taro > commitment is, etc). > > > The above also reminds me of another potential issue which you need to be > > aware of, if you're not already. Similar to my comment about how the > > location of the Taro tree inside the taproot tree needs to be > > deterministic for the verifier, the output in which you place the Taro > > tree also needs to be > > Yep, the location needs to be fully specified which includes factoring the > output index as well. A simple way to restrict this would just to say it's > always the first output. Otherwise, you could lift the output index into > the > asset ID calculation. > > -- Laolu > [-- Attachment #2: Type: text/html, Size: 7833 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay 2022-04-08 17:48 ` Olaoluwa Osuntokun 2022-04-10 16:51 ` Ruben Somsen @ 2022-04-16 2:43 ` Olaoluwa Osuntokun 1 sibling, 0 replies; 12+ messages in thread From: Olaoluwa Osuntokun @ 2022-04-16 2:43 UTC (permalink / raw) To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3921 bytes --] Hi y'all, > In terms of achieving this level of binding within the Taro tree itself, I > can think of three options: The earlier BIP draft just sort of said "the commitment should be unique" and hand waved away the exact algorithm used to verify this key property. I thought about a few ways to do this, but most of them can't work, as the taproot tree is always sorting the siblings before hashing them into a parent. This sorting means that all ordering information is lost, and can't be obtained again afaict. To get around this limitation, I've proposed a concrete scheme here to both verify that the commitment is in a unique place within the tree, and also that it doesn't exist anywhere else in the transaction (assumes widespread usage of BIP 86): https://github.com/Roasbeef/bips/pull/21. A series of inclusion and non-inclusion proofs are used to construct+verify this property. At a high level the scheme takes advantage of the tagged hash scheme used in taproot: leaves use "TapLeaf" as the tag, and branches use "TapBranch" as the tag. Building upon this, we then require the Taro commitment to be in the leftmost/rightmost (remember ordering info is lost) of the tree. From here we can decompose things into a few different cases: * The control block proof is 32 bytes, meaning there's only a single element, so verify the taro commitment and the taproot commitment is correct. * The proof is instead 64 bytes, meaning there's a leaf at depth 1 with a sibling: * If the sibling is a leaf, then verify the pre-image is 32 bytes and the tagged hash calc matches up. * If the sibling is a branch, then verify that hashing the two opaque siblings that make it up gives the same branch (tap hash branch). From the PoV of wallets, this isn't too hard to manage as a Taro library can just take the existing root of the wallet's scripts, and merge that into a new root with the Taro leaf hanging off to the side. As an aside, one thing that's missing in the ecosystem today is a standardized algorithm for constructing a taproot tree given a set of script leaves. The tree constructor has a lot of freedom to do things like put more common things higher up in the tree, or always try to make the tree uniform, etc, etc. The btcsuite libraries use a simple algo [1] I came up with that just merges leaves into branches until there're no leaves left (even number) or there's one leaf, with that last leaf being merged with the final branch. After that you just keep on merging. It's not the most optimized/efficient routine but it's simple which counts for a lot IMO. Admittedly as is defined in my PR above, Taro is a bit demanding w.r.t commitment space: it wants the highest position in the tree as that's easy to verify and makes a smaller proof. The impact for items in the script tree itself isn't too bad as it just means an extra 32 byte hash in the control block proof when it comes to reveal time, and that's witness data which is discounted at the block size level. Zooming out a bit, assuming that applications/protocols start making more structured commitments in the tapscript tree, it may make sense to roll out a distinct BIP that carves out an explicit structure/split. As an example, a new standard could be created that pushes all the actual scripts to the "left" and everything else to the "right". In the "right" part of the tree, we can use w/e tree structure we want, so we aren't bound by the sorting quirk. If each project picks some 32-byte value (a hash of the name or w/e), then another SMT (or w/e other merklalized k-v map) can be used to place each root commitment in a unique location in the tree. Maybe something like this also becomes the basis of future consensus-critical commitments (utxo commitments, etc, etc)? -- Laolu [1]: https://github.com/btcsuite/btcd/blob/99e4e00345017a70eadc4e1d06353c56b23bb15c/txscript/taproot.go#L618 [-- Attachment #2: Type: text/html, Size: 4491 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-04-16 2:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-05 20:23 [bitcoin-dev] Taro: A Taproot Asset Representation Overlay vjudeu 2022-04-06 0:43 ` ZmnSCPxj -- strict thread matches above, loose matches on Subject: below -- 2022-04-11 0:30 Bram Cohen 2022-04-11 18:21 ` Olaoluwa Osuntokun 2022-04-11 21:29 ` Bram Cohen 2022-04-05 15:06 Olaoluwa Osuntokun 2022-04-07 17:14 ` Ruben Somsen 2022-04-08 17:48 ` Olaoluwa Osuntokun 2022-04-10 16:51 ` Ruben Somsen 2022-04-11 19:51 ` Olaoluwa Osuntokun 2022-04-15 13:14 ` Ruben Somsen 2022-04-16 2:43 ` Olaoluwa Osuntokun
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox