Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D2E1AC0012; Thu, 7 Apr 2022 17:14:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id BAAAE612AD; Thu, 7 Apr 2022 17:14:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV39BrUzOHrm; Thu, 7 Apr 2022 17:14:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by smtp3.osuosl.org (Postfix) with ESMTPS id 307BA612AC; Thu, 7 Apr 2022 17:14:16 +0000 (UTC) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-2e5e31c34bfso69046867b3.10; Thu, 07 Apr 2022 10:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mSIPtFzy9SvL9iyJPZhwvJjOxdr7JkyGBQU/F0a+QWM=; b=iEvxShwbaxJfdUj9fzGIrGGqgQpyTF2O2VvsiZ6CgS32yQVzVZP62LWmEdw+TekmpX J0xbTonTx56ADDrG48XgziXc5AGZe1hl9fv86HhzML4+wSVA8dCQaWlNx4AsKKjcMts7 mBC0s6mrX6agKrm7/DxOOUyj3QAFnrBn7DvWB25cfqoxjy0Pu0loAh+YdKmY6gWO4IQl hWJSFB34mPT4/ZfpzLrypa+qKKUFXt7+EIicc/rb+HucRmIVeEXevEWPE0bJZmVGlBgo dUjNszoP3gPLJHbQoDE/HdosLug8+RRuQD9gsNX/jc+buFXt2BG7SpL8WF2+i+J7ln9q YiJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mSIPtFzy9SvL9iyJPZhwvJjOxdr7JkyGBQU/F0a+QWM=; b=3QOVwv3nyMELhzlShq5K8Azx3hMUQI+IdoYZRa45qj0SoF0WmuP23TY/TN8gE0B3nd 1p+j1/vacIHNxLoG6ypA2Vc+EKUQIX0LiImVqNgQcuNYiXWi4AvOGQk2i5efs97kba15 UPKvM2pBk5rKaYa6cpia/CP/UxA355e10TJAOs3kytm3XDHxdM4PN8es8xjtLE7SSEyL 4TlyEMz/5mB6WAJT5Aix5BOXOOJfNiW/Hxa9pU3AMzqKOCCVc/Uo4cmr4qPyV8YhIvkY /sC/V5U2/u7vbvLPhUxaykqxXIwpKCpCLfx8tjfvmQX+N5p5RyV/tKHgtFHxOOpC1rvW oxNg== X-Gm-Message-State: AOAM532fDwccCJRmcuegSbZvE7j1yLb73WtVCeiFWahdNin0zwezMKbC fJ5/zu0+1jytDwEJOHSUtPqcNOFczJaIxfaIGVf1QarBoTg= X-Google-Smtp-Source: ABdhPJzI41ymWcFpv63dPk3Tx8UycdXuRJzrpVhpMD/QihonlVmXaH3la/G+jg9VHBjnqYO0qNfT7XfeemYjistJoxA= X-Received: by 2002:a0d:e743:0:b0:2eb:3106:9b32 with SMTP id q64-20020a0de743000000b002eb31069b32mr12916121ywe.512.1649351654971; Thu, 07 Apr 2022 10:14:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ruben Somsen Date: Thu, 7 Apr 2022 19:14:03 +0200 Message-ID: To: Olaoluwa Osuntokun , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000811bc005dc139baa" X-Mailman-Approved-At: Thu, 07 Apr 2022 17:14:52 +0000 Cc: lightning-dev Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 17:14:18 -0000 --000000000000811bc005dc139baa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=80=93 Dave receives Alice's 2 to= kens, Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice). b.) The token history gets merged =E2=80=93 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 =E2=80=93 when transferring Taro token ownership fr= om 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 whi= ch > 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 a= nd > 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 ca= n > be > expressed in the Taro scripting system. Future versions of the scripting > system > can introduce new functionality on the Taro layer, like covenants or othe= r > 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, whi= ch > 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.mediawik= i > * The Taro flat file proof format: > https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediaw= iki > > Rather than post them all in line (as the text wouldn't fit in the allowe= d > 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 > --000000000000811bc005dc139baa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Laolu,

Nice work. Thi= s is an=C2=A0interesting protocol, in my opinion.

Se= eing 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 i= n that project also apply here.=C2=A0

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 i= nitially be similar to Bitcoin and eventually be made to do more. I'm a= fraid 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 scrip= t, then at the Taro level you have yet another script. This may seem simila= r at first glance to how taproot has a key path and a script path, but ther= e are a few key differences. In taproot only one of the two needs to be sat= isfied, while here you need to satisfy both. Furthermore, the Taro script i= s 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 r= esult.

I'll describe an example. Imagine Alice= wants to send Bob a payment inside Taro, but she wants to make it conditio= nal. Bob gets the Taro tokens if he reveals a pre-image, while Alice can cl= aim 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 multi= sig 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 revea= ls the pre-image. If Bob maliciously broadcasts it without the pre-image, h= e will have destroyed your tokens.

Of course this = was a contrived example, as these conditions could simply take place entire= ly in Bitcoin script, but it demonstrates that Taro script fundamentally ca= nnot handle conditional payments, which is the basis for any meaningful scr= ipt other=C2=A0than self-encumbering covenants (i.e. if you send your Taro = tokens in any way other than specified, the tokens will be destroyed). Luck= ily this has no effect on whether Taro can function over Lightning, because= solely relying on Bitcoin's scripting capabilities should be sufficien= t for that use case.

As a side note, it may be wor= th 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&= #39;s a second issue I want to bring up, but unfortunately my understanding= of how exactly you=C2=A0made assets divisible is not complete enough to kn= ow how this problem might have manifested in Taro. Nonetheless, I'll tr= y 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 recip= ient. In case of an NFT the history is simply every prior owner and grows l= inearly, but in the case of fungible tokens things are more complicated. Le= t'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= =C2=A01. There are two possible designs here:

a.) = The token history remains separate =E2=80=93 Dave receives Alice's 2 to= kens, Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Al= ice).=C2=A0

b.) The token history gets merged =E2= =80=93 Dave receives 4 tokens (linking the new output with both Alice and B= ob's history).

The issue with a.) is that you&= #39;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 s= uspect the fixed value token model (e.g. 1, 2, 4, 8) might be preferable, a= s 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 co= uld have come from many of them. The graph that you'd traverse to get t= o all of these coinbases is equivalent to the amount of history that a reci= pient of a Taro token has to validate in order to accept it, which I suspec= t quickly becomes a bottleneck that is not unlike that of a regular blockch= ain.

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 generall= y get a better idea of how it affects scaling. Also, the repeated sharing o= f history makes me skeptical about the privacy this protocol may provide. I= f large amounts of history moved through the hands of a large number of peo= ple, it wouldn't be very private.

There's = a third third smaller issue I want to point out, which is easily fixable an= d perhaps was just a typo. In your slides, you showed a screenshot of a tap= root tree containing the Taro tree as the third element of four. This impli= es 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 T= aro tree, as that would enable the owner of the commitment to show differen= t histories to different people.

Finally, let me c= onclude with two questions. Could you clarify the=C2=A0purpose of the=C2=A0= 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 an= y of the other assets and simultaneously guarantee that you haven't com= mitted to the same asset twice (i.e. the SMT guarantees each asset gets a s= pecific location in the tree)? Or is there another reason?

And the second question =E2=80=93 when transferring Taro token own= ership 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 co= nsideration 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=C2=A0hope this email was useful. Feel = free to reach out if I can clarify anything.

Good = luck with the protocol.

Best regards,
Ru= ben

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 worki= ng on over the
past few months: Taro. Taro is a Taproot Asset Representa= tion Overlay which
allows the issuance of normal and also collectible as= sets on the main Bitcoin
chain. Taro uses the Taproot script tree to com= mit extra asset structured meta
data based on a hybrid merkle tree I cal= l a Merkle Sum Sparse Merkle Tree or
MS-SMT. An MS-SMT combined the prop= erties 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 th= e 1-of-1 holographic beefzard card during our swap). Taro asset
transfer= s are then embedded in a virtual/overlay transaction graph which uses a
= chain of asset witnesses to provably track the transfer of assets acrosstaproot outputs. Taro also has a scripting system, which allows for
pro= grammatic unlocking/transfer of assets. In the first version, the scripting=
system is actually a recursive instance of the Bitcoin Script Taproot V= M,
meaning anything that can be expressed in the latest version of Scrip= t 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 integr= ation 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 p= rotocol proposes to instead only recognize "assets at the edges",=
which means that only the sender+receiver actually need to know about a= nd
validate the assets. This deployment route means that we don't ne= ed to build up
an entirely new network and liquidity for each asset. Ins= tead, all asset
transfers will utilize the Bitcoin backbone of the Light= ning Network, which
means that the internal routers just see Bitcoin tra= nsfers 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 (s= ay 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 sui= te, with the following breakdown:
=C2=A0* The main Taro protocol: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.medi= awiki
=C2=A0* The MS-SMT structure: http= s://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki=C2=A0* The Taro VM: https://github.com/Roasbeef/b= ips/blob/bip-taro/bip-taro-vm.mediawiki
=C2=A0* The Taro address for= mat: https://github.com/Roasbeef/bips/blob/bip-ta= ro/bip-taro-addr.mediawiki
=C2=A0* The Taro Universe concept: https://github.com/Roasbeef/bips/blob/bip-taro/bip-= taro-universe.mediawiki
=C2=A0* The Taro flat file proof format: =C2= =A0https://github.com/Roasbeef/bips/blob/bi= p-taro/bip-taro-proof-file.mediawiki

Rather than post them all i= n 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/mail= man/listinfo/bitcoin-dev
--000000000000811bc005dc139baa--