From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7ED3EC002D; Thu, 3 Nov 2022 09:26:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4441640457; Thu, 3 Nov 2022 09:26:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4441640457 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=YDZEDWaI 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 Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpIXP8kSRiqq; Thu, 3 Nov 2022 09:26:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 165E741553 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by smtp4.osuosl.org (Postfix) with ESMTPS id 165E741553; Thu, 3 Nov 2022 09:26:18 +0000 (UTC) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-367cd2807f2so9823857b3.1; Thu, 03 Nov 2022 02:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=INB5ouLpgsuMg9nD/IVEIP/S1Z4zjcU7QrhQxEiWoLk=; b=YDZEDWaIY2C4eE7ncNchmFNZWfQvZBbEyeyDrqg3HhaSUIXGemUL7aWOmQ7VNKETPx jAzwo5m7BL2nlrj2jdTBs36qfCZneY46IgzIGiESC97il5Wjp2tLaW8AwoTVQSKlOvSf nwT2vkQcRT1c4DVZizdKbPVBXuSmlpddtmXTEe0KggaJZhISwZkiTk5vy95cj41oU67h xqmo1goxKEb0P5yVmz1e5BzDos4l0akajzDErsDgmEIgMmvSTcOMBA6yPxkfO82mxuSj ae3sec28Utzr6dVZnNe8UNGoteTeSZjQxnmzMLXH3my4sE6wiPpSWek/O/rdGUwANRSq lDtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=INB5ouLpgsuMg9nD/IVEIP/S1Z4zjcU7QrhQxEiWoLk=; b=r1I1ydzX7yBqSLeQEH/S9POyX7otvpnlmLrxvHYsiMkqW9FS/bbflcxi55+wjVByzm cEh528H6Z9gg22utifD+WR7GfAR9tdl4DLZOc4wAU39Nbv/L231k3iJKm3miVXq98/nh IcwyD5/t7JuTfpZ8QN5cTq82BiIPXcN3pOhFk77eF4jSB8ww2dBN40Osz1Ykd0YLPSfC uzCizwtrGqyHYw1OwDwAkCgwDhfGBx2QuRDXySM3E+VwtgVuvZ0MA3IB8JfEqRsV14t0 vmLWRSRKz7gqufUOJmJOV2Kr4OBeGpgVjE1omsZQ+hj2GibYNgyDHmmMZbLU2QdBTo71 Q+cQ== X-Gm-Message-State: ACrzQf3/tLKPheOYXbImTG2QwAz2P0fnRvKLuwaEgbfl1ySgMsYty6sr OMhYBuX1NJyW+SZxzaWRG8SQ4GnHjaHwNVJb1TSHbuVlc/FQ5g== X-Google-Smtp-Source: AMsMyM4n7vvL8KKlr/jbVhBeHGcH41u25KM5NRvrg7RwzshluAOiHQmzhO0+ZQGwPUcsxt+pLAi1W8rbtByOvhom7pI= X-Received: by 2002:a0d:e7c6:0:b0:370:45f7:aaa1 with SMTP id q189-20020a0de7c6000000b0037045f7aaa1mr24056225ywe.226.1667467576792; Thu, 03 Nov 2022 02:26:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= Date: Thu, 3 Nov 2022 10:26:05 +0100 Message-ID: To: Ruben Somsen Content-Type: multipart/alternative; boundary="00000000000096da1c05ec8d8cfa" X-Mailman-Approved-At: Thu, 03 Nov 2022 09:35:37 +0000 Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-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, 03 Nov 2022 09:26:21 -0000 --00000000000096da1c05ec8d8cfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I wanted to chime in on the "teleport" feature explained by Ruben, as I think exploring something similar for Taro could be super useful in an LN setting. In today's Taro, to transfer tokens you have to spend a UTXO, and present a proof showing that there are tokens committed to in the output you are spending. Let's say this UTXO is 'utxo:0'. In contrast, to spend teleported tokens, you would still spend utxo:0, but you would only have to present a proof that _some txout_ on-chain have committed tokens to utxo:0. As Ruben points out, this makes it possible to send tokens to an already spent TXO, essentially burning the tokens. However, it opens up some exciting possibilities IMO. You can in essence use this to "re-fill" UTXOs with tokens, which is very interesting for LN channels: - You could "add" tokens to your already open channels. The only thing needed is for the channel participants to be presented the proof that tokens were sent to the funding output, and they can update their commitment transaction to start spending these tokens. - You can "top-up" all your channels in a single on-chain tx. Since a single output can commit tokens to several UTXOs, you could with a single on-chain transaction add tokens to many channels without opening and closing them. RGB also has the ability to "blind" the UTXO that tokens get teleported to, hiding the recipient UTXO. This is cool, since I could withdraw tokens from an exchange directly into my LN channel, without revealing my channel UTXO. I found the explanation of the teleport feature in this blog post pretty good: https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059 - Johan On Sun, Apr 10, 2022 at 6:52 PM Ruben Somsen wrote: > Hi Laolu, > > >happy to hear that someone was actually able to extract enough details > from the RGB devs/docs to be able to analyze it properly > > Actually, even though I eventually puzzled everything together, this did > not go well for me either. There is a ton of documentation, but it's a ma= ze > of unhelpful details, and none of it clearly maps out the fundamental > design. I was also disappointed by the poor response I received when aski= ng > 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 scratc= h > 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 wou= ld > 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 w= e > 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 sma= rt > 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 =E2=80=93 not very useful. Anything involving a conditional transfer= of > ownership to either A or B (i.e. any meaningful type of script) won't wor= k. > Do you see what I mean, or should I elaborate further? > > >TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transi= tions > 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 maki= ng > 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 outpu= t, > make a new output for Bob, and make a change output for herself. Inside t= he > Taro tree you'll then point to the index of Bob's output in order to assi= gn > 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, thu= s > "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 determinist= ic > 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 > 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 o= f >> 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 i= n >> 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 desig= n >> (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 t= he >> 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 possib= le >> 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 avoi= d >> 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 functio= n >> of >> the Taro commitment being present. >> >> > There are two possible designs here: a.) The token history remains >> separate =E2=80=93 >> > 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 =E2=80=93= 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 t= he >> 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 Bitcoi= n >> 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 grap= h >> 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 t= o >> 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 outpoi= nt >> 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 th= e >> 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 tr= ee >> 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 differen= t >> 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 mo= re >> units that exist (so I make sure I don't get an invalid split). >> >> > And the second question =E2=80=93 when transferring Taro token ownersh= ip 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 provide= d >> 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 cohere= nt >> 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=3D20&t=3DfeV0k= WAjJ6MTQlFm06tSxA >> [2]: >> https://twitter.com/roasbeef/status/1330692571736117249?s=3D20&t=3DfeV0k= WAjJ6MTQlFm06tSxA >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > --00000000000096da1c05ec8d8cfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I wanted to chime in on the "teleport" fea= ture explained by Ruben, as I think exploring something similar for Taro co= uld be super useful in an LN setting.

In today'= ;s Taro, to transfer tokens you have to spend a UTXO, and present=C2=A0a pr= oof showing that there are tokens committed to in the output you are spendi= ng. Let's say this UTXO is 'utxo:0'.=C2=A0

=
In contrast, to spend teleported tokens, you would still spend utxo:0,= but you would only have to present a proof=C2=A0that _some txout_ on-chain= have committed=C2=A0tokens to utxo:0.=C2=A0

As Ru= ben points out, this makes it possible to send tokens to an already spent T= XO, essentially burning the tokens.=C2=A0

However,= it opens up some exciting possibilities=C2=A0IMO. You can in essence use t= his to "re-fill" UTXOs with tokens, which is very interesting for= LN channels:

- You could "add" tokens t= o your already open channels. The only thing needed is for the channel part= icipants to be presented the proof that tokens were sent to the funding out= put, and they can update their commitment transaction to start spending the= se tokens.
- You can "top-up" all your channels in a si= ngle on-chain tx. Since a single output can commit tokens to several UTXOs,= you could with a single on-chain transaction add tokens to many channels w= ithout opening and closing them.

RGB also has the = ability to "blind" the UTXO that tokens get teleported to, hiding= the recipient UTXO. This is cool, since I could withdraw tokens from an ex= change directly into my LN channel, without revealing my channel UTXO.
<= /div>

I found the explanation of the teleport feature in= this blog post pretty good:=C2=A0https://medium.com/@FedericoTe= nga/understanding-rgb-protocol-7dc7819d3059

- = Johan

On Sun, Apr 10, 2022 at 6:52 PM Ruben Somsen <rsomsen@gmail.com> wrote:
=
Hi Laolu= ,

>happy to hear t= hat someone was actually able to extract enough details from=C2=A0the 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 cl= early 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=C2= =A0decision to rebuild from scratch seems right to me.

That sai= d, in my opinion the above should not factor into the decision of whether R= GB should be credited in the Taro documentation. The design clearly precede= s (and seems to have inspired) Taro, so in my opinion this should be acknow= ledged. 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 t= he originators either=C2=A0(Peter= Todd,=C2=A0Alekos Filini,=C2=A0G= iacomo Zucco).
<= font color=3D"#500050">
>assets can=C2=A0be burnt if a user doesn't supply a valid witne= ss

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 n= ot make sense to build scripting support into Taro, because you can't a= ctually do anything interesting with it due to this limitation. The only ty= pe of smart contract you can build is one where you limit what the owner (a= s defined by Bitcoin's script) can do with their own Taro tokens, or el= se he will burn them =E2=80=93 not very useful. Anything involving a condit= ional transfer of ownership to either A or B (i.e. any meaningful type of s= cript) won't work. Do you see what I mean, or should I elaborate furthe= r?

>TAPLEAF_UPDATE= _VERIFY can actually be used to further=C2=A0_bind_=C2=A0Taro=C2=A0transitions at the Bitcoin level= , without Bitcoin explicitly=C2=A0needing to be aware
That is conceptually= quite interesting. So theoretically you could get Bitcoin covenants to enf= orce certain spending conditions on Taro assets. Not sure how practical tha= t ends up being, but intriguing to consider.

>asset issuer to do a &quo= t;re-genesis"
=
Yes, RGB suggested the same thing, and this can work under s= ome 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 m= aking things worse, as now everyone has to verify it). And of course the=C2= =A0idea also requires the issuer to be active, which may not always be the = case.

>I'm not familiar with how the RGB &q= uot;teleport" technique works [...] Can you point me to a coherent exp= lanation of the technique

To my knowledge no g= ood 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 out= put 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 simultan= eously sending tokens to it, as I mentioned in my previous post, as this wo= uld destroy the tokens).

The above also reminds me= of another potential issue which you need to be aware of, if you're no= t already. Similar to my comment about how the location of the Taro tree in= side the taproot tree needs to be deterministic for the verifier, the outpu= t 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 th= is helps.

Cheers,
Ruben

On Fri, Apr 8, 2022 at 7:48 PM Olaoluwa Osuntokun &l= t;laolu32@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">(this might be a double post as it ran into the size limit)=

Hi Ruben,

Thanks! I don't really consid= er things final until we have a good set of test
vectors in the final se= t, after which we'd start to transition the set of
documents beyond = the draft state.

> Seeing as there's a large amount of overla= p with RGB, a protocol which I have
> examined quite extensively, I b= elieve some of the issues I uncovered in that
> project also apply he= re.

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 kno= w, or they hadn't finished the core design
(large TBD sections) as t= hey were working on adding other components to create
a "new new In= ternet".

> Furthermore, the Taro script is not enforced by B= itcoin, meaning those who
> control the Bitcoin script can always cho= ose to ignore the Taro script and
> destroy the Taro assets as a resu= lt.

This is correct, as a result in most contexts, an incentive exis= ts for the
holder of an asset to observe the Taro validation rules as ot= herwise, their
assets are burnt in the process from the PoV of asset ver= ifiers. In the single
party case things are pretty straight forward, but= more care needs to be taken
in cases where one attempts to express part= ial 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&= #39;re likely ways to get
around this by lessening the binding to Bitcoi= n UTXO's, but then the system
would need to be able to collect, reta= in and order all the set of possible
spends, essentially requiring a par= allel network. The core of the system as it
stands today is pretty simpl= e (which was an explicit design goal to avoid
getting forever distracted= by the large design space), with a minimal
implementation being relativ= ely compact given all the Bitcoin context/design
re-use.

Also one= cool trait of the way commitments are designed is that the Taro
commitm= ent impact the final derived taproot output key. As a result, potential
= Script extensions like TAPLEAF_UPDATE_VERIFY can actually be used to furthe= r
_bind_ Taro transitions at the Bitcoin level, without Bitcoin explicit= ly
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, wh= ich is a function of
the Taro commitment being present.

> Ther= e are two possible designs here: a.) The token history remains separate =E2= =80=93
> Dave receives Alice's 2 tokens, Bob's tokens are spl= it and he receives 2 (or
> 3 from Bob 1 from Alice). =C2=A0b.) The to= ken history gets merged =E2=80=93 Dave receives
> 4 tokens (linking t= he new output with both Alice and Bob's history).

Mechanically, = with respect to the way the change/UTXOs work in the system, both
are ex= pressible: Dave can chose to merge them into a single UTXO (with the
app= ropriate witnesses included for each of them), or Dave can keep them
dis= tinct in the asset tree. You're correct in that asset issuers may opt t= o
issue assets in denominations vs allowing them to be fully divisible.<= br>Ultimately, the compatibility with the LN layer will be the primary way = to keep
asset histories compressed, without relying on another trust mod= el, or relying
on the incentive of an asset issuer to do a "re-gene= sis" which would
effectively re-create assets in a supply-preservin= g manner (burn N units, then
produce a new genesis outpoint for N units)= . Alternatively, implementations can
also chose to utilize a checkpointi= ng system similar to what some Bitcoin full
node clients do today.
> =C2=A0is that you end up with a linked transaction graph, just like = in Bitcoin

This is correct, the protocol doesn't claim to achiev= e better privacy
guarantees than the base chain. However inheriting this= transaction graph model
imo makes it easier for existing Bitcoin develo= pers to interact with the
system, and all the data structures are very f= amiliar tooling wise. However any
privacy enhancing protocol used for on= -chain top-level Bitcoin UTXOs can also
be applied to Taro, so people ca= n use things like coinswap and coinjoin, along
with LN to shed prior coi= n lineages.

> This implies the location of the Taro tree inside t= he taproot tree is not
> fixed. What needs to be prevented here is th= at a taproot tree contains more
> than one Taro tree, as that would e= nable the owner of the commitment to show
> different histories to di= fferent people.

Great observation, I patched a similar issue much ea= rlier in the design process
by strongly binding all signatures to a prev= Out super-set (so the outpoint
along with the unique key apth down into = the tree), which prevents duplicating
the asset across outputs, as signa= ture verification would fail.

In terms of achieving this level of bi= nding within the Taro tree itself, I can
think of three options:

= =C2=A0 1. Require the Taro commitment to be in the first/last position with= in the
=C2=A0 (fully sorted?) Tapscript tree, and also require its sibli= ng to be the hash
=C2=A0 of some set string (all zeroes or w/e). We'= d require the sibling to the empty
=C2=A0 as the tapscript hashes are so= rted before hashing so you sort of lose that
=C2=A0 final ordering infor= mation.

=C2=A0 2. Include the position of the Taro commitment within= the tapscript tree
=C2=A0 within the sighash digest (basically the way = the single input in the virtual
=C2=A0 transaction is created from the T= LV structure).

=C2=A0 3. Include the position of the Taro commitment= within the tapscript tree as
=C2=A0 part of the message that's hash= ed to derive asset IDs.

AFAICT, #1 resolves the issue entirely, #2 r= enders transfers outside of the
canonical history invalid, and #2 minds = hte asset ID to the initial position
meaning you can track a canonical l= ineage from the very start.

> Finally, let me conclude with two q= uestions. Could you clarify the purpose of
> the sparse merkle tree i= n your design?

Sure, it does a few things:

=C2=A0 * Non-incl= usion proofs so I can do things like prove to your I'm no longer
=C2= =A0 =C2=A0 committing to my 1-of-1 holographic beefzard card when we swap.<= br>
=C2=A0 * The key/tree structure means that the tree is history indep= endent, meaning
=C2=A0 =C2=A0 that if you and I insert the same things i= nto the tree in a different
=C2=A0 =C2=A0 order, we'll get the same = root hash. This is useful for things like
=C2=A0 =C2=A0 tracking all the= issuance events for a given asset, or allowing two
=C2=A0 =C2=A0 entiti= es to sync their knowledge/history of a single asset, or a set of
=C2=A0= =C2=A0 assets.

=C2=A0 * Each asset/script mapping to a unique locat= ion within the tree means it's
=C2=A0 =C2=A0 easy to ensure uniquene= ss of certain items/commitments (not possible to
=C2=A0 =C2=A0 commit to= the same asset ID twice in the tree as an example).

=C2=A0 * The me= rkle-sum trait means I that validation is made simpler, as you just
=C2= =A0 =C2=A0 check that the input+output commitment sum to the same value, an= d I can
=C2=A0 =C2=A0 also verify that if we're swapping, then you a= ren't committing to more
=C2=A0 =C2=A0 units that exist (so I make s= ure I don't get an invalid split).

> And the second question = =E2=80=93 when transferring Taro token ownership from one
> Bitcoin U= TXO to another, do you generate a new UTXO for the recipient or do
> = you support the ability to "teleport" the tokens to an existing U= TXO like how
> RGB does it? If the latter, have you given considerati= on to timing issues
> that might occur when someone sends tokens to a= n existing UTXO that
> simultaneously happens to get spent by the own= er?

So for interactive transfers, the UTXOs generated as just the on= es 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=C2=A0decks a while
back, but = they were mostly about all the new components they were creating and
the= ir 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 an= alyze
the diff tradeoffs being made here.

Thanks for an initial r= ound of feedback/analysis, I'll be updating the draft
over the next = few days to better spell things out and particularly that
commitment/sig= hash uniqueness trait.

-- Laolu

[1]: https://twitter.com/roasbeef/status/13306549360743= 71073?s=3D20&t=3DfeV0kWAjJ6MTQlFm06tSxA
[2]: https://twitter.com/roasbeef/status/133069257= 1736117249?s=3D20&t=3DfeV0kWAjJ6MTQlFm06tSxA
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
--00000000000096da1c05ec8d8cfa--