MIME-Version: 1.0
References: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com>
 <CAPv7TjYTjvSV7UFgOwif6tFj3jVxDfJdW-p_cyPoAGGWKQbwRQ@mail.gmail.com>
 <CAO3Pvs_-igT37fcD29=ATSRX7dW5mGKrLGrXp=iJjaN_t3NGww@mail.gmail.com>
In-Reply-To: <CAO3Pvs_-igT37fcD29=ATSRX7dW5mGKrLGrXp=iJjaN_t3NGww@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sun, 10 Apr 2022 18:51:52 +0200
Message-ID: <CAPv7TjZjZU2bYvUrt-BEx80xKF=BHBbrYWigHB+=yY+YfZX9Yg@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b5d66805dc4fa5d6"
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Precedence: list

--000000000000b5d66805dc4fa5d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=93 not very useful. Anything involving a conditional transfer o=
f
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 transiti=
ons
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 detail=
s
> 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 th=
e
> holder of an asset to observe the Taro validation rules as otherwise, the=
ir
> 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 relate=
d
> 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 t=
o
> get
> around this by lessening the binding to Bitcoin UTXO's, but then the syst=
em
> would need to be able to collect, retain and order all the set of possibl=
e
> 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 =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 th=
e
> 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 t=
o
> 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 Bitco=
in
>
> 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 n=
ot
> > 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 outpoin=
t
> 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 tre=
e
>   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 tre=
e
> as
>   part of the message that's hashed to derive asset IDs.
>
> AFAICT, #1 resolves the issue entirely, #2 renders transfers outside of t=
he
> 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 c=
an
>     also verify that if we're swapping, then you aren't committing to mor=
e
>     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 ownershi=
p from one
> > Bitcoin UTXO to another, do you generate a new UTXO for the recipient o=
r
> 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 issu=
es
> > 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 o=
f
> 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 familia=
r
> 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 creatin=
g
> and
> their milestone of 1 million lines of code. Can you point me to a coheren=
t
> 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=3DfeV0kW=
AjJ6MTQlFm06tSxA
> [2]:
> https://twitter.com/roasbeef/status/1330692571736117249?s=3D20&t=3DfeV0kW=
AjJ6MTQlFm06tSxA
>

--000000000000b5d66805dc4fa5d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Laolu,<div><br></div><div>&gt;<span style=3D"color:rgb(=
80,0,80)">happy to hear that someone was actually able to extract enough de=
tails from=C2=A0</span><span style=3D"color:rgb(80,0,80)">the RGB devs/docs=
 to be able to analyze it properly</span></div><div><span style=3D"color:rg=
b(80,0,80)"><br></span></div><div><font color=3D"#500050">Actually, even th=
ough I eventually puzzled everything together, this did not go well for me =
either. There is a ton of documentation, but it&#39;s a maze of unhelpful d=
etails, 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 e=
nded 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 i=
n great shape, so the=C2=A0decision to rebuild from scratch seems right to =
me.</font></div><div><font color=3D"#500050"><br></font></div><div><font co=
lor=3D"#500050">That said, in my opinion the above should not factor into t=
he decision of whether RGB should be credited in the Taro documentation. Th=
e design clearly precedes (and seems to have inspired) Taro, so in my opini=
on this should be acknowledged. Also, the people that are responsible for t=
he current shape of RGB aren&#39;t the people who originated the idea, so i=
t would not be fair to the originators either=C2=A0</font><span style=3D"co=
lor:rgb(80,0,80)">(Peter Todd,=C2=A0</span>Alekos Filini,<span style=3D"col=
or:rgb(80,0,80)">=C2=A0Giacomo Zucco)</span><span style=3D"color:rgb(80,0,8=
0)">.</span></div><div><font color=3D"#500050"><br></font></div><div><font =
color=3D"#500050">&gt;</font><span style=3D"color:rgb(80,0,80)">assets can=
=C2=A0</span><span style=3D"color:rgb(80,0,80)">be burnt if a user doesn=
9;t supply a valid witness</span></div><div><font color=3D"#500050"><br></f=
ont></div><div><font color=3D"#500050">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 t=
o say was that it does not make sense to build scripting support into Taro,=
 because you can&#39;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&#39;s script) can do with thei=
r own Taro tokens, or else he will burn them =E2=80=93 not very useful. Any=
thing involving a conditional transfer of ownership to either A or B (i.e. =
any meaningful type of script) won&#39;t work. Do you see what I mean, or s=
hould I elaborate further?</font></div><div><font color=3D"#500050"><br></f=
ont></div><div><font color=3D"#500050">&gt;</font><span style=3D"color:rgb(=
80,0,80)">TAPLEAF_UPDATE_VERIFY can actually be used to further=C2=A0</span=
><span style=3D"color:rgb(80,0,80)">_bind_=C2=A0</span><span style=3D"color=
:rgb(80,0,80)">Taro</span><span style=3D"color:rgb(80,0,80)">=C2=A0transiti=
ons at the Bitcoin level, without Bitcoin explicitly=C2=A0</span><span styl=
e=3D"color:rgb(80,0,80)">needing to be aware</span></div><div><span style=
=3D"color:rgb(80,0,80)"><br></span></div><div><span style=3D"color:rgb(80,0=
,80)">That is conceptually quite interesting. So theoretically you could ge=
t Bitcoin covenants to enforce certain spending conditions on Taro assets. =
Not sure how practical that ends up being, but intriguing to consider.</spa=
n></div><div><span style=3D"color:rgb(80,0,80)"><br></span></div><div>&gt;a=
sset issuer to do a &quot;re-genesis&quot;<span style=3D"color:rgb(80,0,80)=
"><br></span></div><div><br></div><div>Yes, RGB suggested the same thing, a=
nd this can work under some circumstances, but note that this won&#39;t hel=
p 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&#39;d actually be making things worse, as now everyone has to verify i=
t). And of course the=C2=A0idea also requires the issuer to be active, whic=
h may not always be the case.</div><div><br></div><div>&gt;I&#39;m not fami=
liar with how the RGB &quot;teleport&quot; technique works [...] Can you po=
int me to a coherent explanation of the technique<br></div><div><br></div><=
div>To my knowledge no good explanation exists. &quot;Teleporting&quot; is =
just what I thought was a good way of describing it. Basically, in your des=
ign when Alice wants to send a Taro token to Bob, Alice has to spend her ow=
n output, make a new output for Bob, and make a change output for herself. =
Inside the Taro tree you&#39;ll then point to the index of Bob&#39;s output=
 in order to assign the tokens to his new output. Instead of pointing to th=
e index, you could point to the outpoint (txid, index) of an existing UTXO =
owned by Bob, thus &quot;teleporting&quot; the Taro tokens to this UTXO. Th=
is saves on-chain space, as now you don&#39;t have to create a new output f=
or Bob (but now you have to ensure Bob doesn&#39;t spend from this output w=
hile you&#39;re simultaneously sending tokens to it, as I mentioned in my p=
revious post, as this would destroy the tokens).</div><div><br></div><div>T=
he above also reminds me of another potential issue which you need to be aw=
are of, if you&#39;re not already. Similar to my comment about how the loca=
tion 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&#39;s not, then you can commit to a different Taro tree in each out=
put of the transaction, allowing you to secretly fork the history.</div><di=
v><br></div><div>Hope this helps.</div><div><br></div><div>Cheers,</div><di=
v>Ruben</div><div><div><br></div><div>[1] <a href=3D"https://twitter.com/So=
msenRuben/status/1397267261619064836" target=3D"_blank">https://twitter.com=
/SomsenRuben/status/1397267261619064836</a><font color=3D"#500050"><br></fo=
nt></div><div>[2] <a href=3D"https://twitter.com/SomsenRuben/status/1397559=
406565462017" target=3D"_blank">https://twitter.com/SomsenRuben/status/1397=
559406565462017</a><br></div><div>[3] <a href=3D"https://twitter.com/afilin=
i/status/1397484341236797441" target=3D"_blank">https://twitter.com/afilini=
/status/1397484341236797441</a><br></div></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 8, 2022 at 7:48 =
PM Olaoluwa Osuntokun &lt;<a href=3D"mailto:laolu32@gmail.com" target=3D"_b=
lank">laolu32@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr">(this might be a double post as it =
ran into the size limit)<br><div><br></div><div>Hi Ruben, <br><br>Thanks! I=
 don&#39;t really consider things final until we have a good set of test<br=
>vectors in the final set, after which we&#39;d start to transition the set=
 of<br>documents beyond the draft state.<br><br>&gt; Seeing as there&#39;s =
a large amount of overlap with RGB, a protocol which I have<br>&gt; examine=
d quite extensively, I believe some of the issues I uncovered in that<br>&g=
t; project also apply here. <br><br>I&#39;m happy to hear that someone was =
actually able to extract enough details from<br>the RGB devs/docs to be abl=
e to analyze it properly! In the past I tried to ask<br>their developers qu=
estions about how things like transfers worked[1][2], but it<br>seemed eith=
er people didn&#39;t know, or they hadn&#39;t finished the core design<br>(=
large TBD sections) as they were working on adding other components to crea=
te<br>a &quot;new new Internet&quot;.<br><br>&gt; Furthermore, the Taro scr=
ipt is not enforced by Bitcoin, meaning those who<br>&gt; control the Bitco=
in script can always choose to ignore the Taro script and<br>&gt; destroy t=
he Taro assets as a result.<br><br>This is correct, as a result in most con=
texts, an incentive exists for the<br>holder of an asset to observe the Tar=
o validation rules as otherwise, their<br>assets are burnt in the process f=
rom the PoV of asset verifiers. In the single<br>party case things are pret=
ty straight forward, but more care needs to be taken<br>in cases where one =
attempts to express partial application and permits anyone<br>to spend a UT=
XO in question. <br><br>By strongly binding all assets to Bitcoin UTXOs, we=
 resolve issues related to<br>double spending or duplicate assets, but need=
s to mind the fact that assets can<br>be burnt if a user doesn&#39;t supply=
 a valid witness. There&#39;re likely ways to get<br>around this by lesseni=
ng the binding to Bitcoin UTXO&#39;s, but then the system<br>would need to =
be able to collect, retain and order all the set of possible<br>spends, ess=
entially requiring a parallel network. The core of the system as it<br>stan=
ds today is pretty simple (which was an explicit design goal to avoid<br>ge=
tting forever distracted by the large design space), with a minimal<br>impl=
ementation being relatively compact given all the Bitcoin context/design<br=
>re-use.<br><br>Also one cool trait of the way commitments are designed is =
that the Taro<br>commitment impact the final derived taproot output key. As=
 a result, potential<br>Script extensions like TAPLEAF_UPDATE_VERIFY can ac=
tually be used to further<br>_bind_ Taro transitions at the Bitcoin level, =
without Bitcoin explicitly <br>needing to be aware of the Taro rules. In sh=
ort, covenants can allow Bitcoin<br>Script to bind Taro state transitions, =
without any of the logic bleeding over,<br>as the covenant just checks for =
a certain output key, which is a function of<br>the Taro commitment being p=
resent.<br><br>&gt; There are two possible designs here: a.) The token hist=
ory remains separate =E2=80=93<br>&gt; Dave receives Alice&#39;s 2 tokens, =
Bob&#39;s tokens are split and he receives 2 (or<br>&gt; 3 from Bob 1 from =
Alice). =C2=A0b.) The token history gets merged =E2=80=93 Dave receives<br>=
&gt; 4 tokens (linking the new output with both Alice and Bob&#39;s history=
).<br><br>Mechanically, with respect to the way the change/UTXOs work in th=
e system, both<br>are expressible: Dave can chose to merge them into a sing=
le UTXO (with the<br>appropriate witnesses included for each of them), or D=
ave can keep them<br>distinct in the asset tree. You&#39;re correct in that=
 asset issuers may opt to<br>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<br>asset histories compressed, without rely=
ing on another trust model, or relying<br>on the incentive of an asset issu=
er to do a &quot;re-genesis&quot; which would<br>effectively re-create asse=
ts in a supply-preserving manner (burn N units, then<br>produce a new genes=
is outpoint for N units). Alternatively, implementations can<br>also chose =
to utilize a checkpointing system similar to what some Bitcoin full<br>node=
 clients do today.<br><br>&gt; =C2=A0is that you end up with a linked trans=
action graph, just like in Bitcoin<br><br>This is correct, the protocol doe=
sn&#39;t claim to achieve better privacy<br>guarantees than the base chain.=
 However inheriting this transaction graph model<br>imo makes it easier for=
 existing Bitcoin developers to interact with the<br>system, and all the da=
ta structures are very familiar tooling wise. However any<br>privacy enhanc=
ing protocol used for on-chain top-level Bitcoin UTXOs can also<br>be appli=
ed to Taro, so people can use things like coinswap and coinjoin, along<br>w=
ith LN to shed prior coin lineages.<br><br>&gt; This implies the location o=
f the Taro tree inside the taproot tree is not<br>&gt; fixed. What needs to=
 be prevented here is that a taproot tree contains more<br>&gt; than one Ta=
ro tree, as that would enable the owner of the commitment to show<br>&gt; d=
ifferent histories to different people.<br><br>Great observation, I patched=
 a similar issue much earlier in the design process<br>by strongly binding =
all signatures to a prevOut super-set (so the outpoint<br>along with the un=
ique key apth down into the tree), which prevents duplicating<br>the asset =
across outputs, as signature verification would fail.<br><br>In terms of ac=
hieving this level of binding within the Taro tree itself, I can<br>think o=
f three options:<br><br>=C2=A0 1. Require the Taro commitment to be in the =
first/last position within the<br>=C2=A0 (fully sorted?) Tapscript tree, an=
d also require its sibling to be the hash<br>=C2=A0 of some set string (all=
 zeroes or w/e). We&#39;d require the sibling to the empty<br>=C2=A0 as the=
 tapscript hashes are sorted before hashing so you sort of lose that<br>=C2=
=A0 final ordering information.<br><br>=C2=A0 2. Include the position of th=
e Taro commitment within the tapscript tree<br>=C2=A0 within the sighash di=
gest (basically the way the single input in the virtual<br>=C2=A0 transacti=
on is created from the TLV structure).<br><br>=C2=A0 3. Include the positio=
n of the Taro commitment within the tapscript tree as<br>=C2=A0 part of the=
 message that&#39;s hashed to derive asset IDs.<br><br>AFAICT, #1 resolves =
the issue entirely, #2 renders transfers outside of the<br>canonical histor=
y invalid, and #2 minds hte asset ID to the initial position<br>meaning you=
 can track a canonical lineage from the very start.<br><br>&gt; Finally, le=
t me conclude with two questions. Could you clarify the purpose of<br>&gt; =
the sparse merkle tree in your design? <br><br>Sure, it does a few things:<=
br><br>=C2=A0 * Non-inclusion proofs so I can do things like prove to your =
I&#39;m no longer<br>=C2=A0 =C2=A0 committing to my 1-of-1 holographic beef=
zard card when we swap.<br><br>=C2=A0 * The key/tree structure means that t=
he tree is history independent, meaning<br>=C2=A0 =C2=A0 that if you and I =
insert the same things into the tree in a different<br>=C2=A0 =C2=A0 order,=
 we&#39;ll get the same root hash. This is useful for things like<br>=C2=A0=
 =C2=A0 tracking all the issuance events for a given asset, or allowing two=
<br>=C2=A0 =C2=A0 entities to sync their knowledge/history of a single asse=
t, or a set of<br>=C2=A0 =C2=A0 assets.<br><br>=C2=A0 * Each asset/script m=
apping to a unique location within the tree means it&#39;s<br>=C2=A0 =C2=A0=
 easy to ensure uniqueness of certain items/commitments (not possible to<br=
>=C2=A0 =C2=A0 commit to the same asset ID twice in the tree as an example)=
.<br><br>=C2=A0 * The merkle-sum trait means I that validation is made simp=
ler, as you just<br>=C2=A0 =C2=A0 check that the input+output commitment su=
m to the same value, and I can<br>=C2=A0 =C2=A0 also verify that if we&#39;=
re swapping, then you aren&#39;t committing to more<br>=C2=A0 =C2=A0 units =
that exist (so I make sure I don&#39;t get an invalid split).<br><br>&gt; A=
nd the second question =E2=80=93 when transferring Taro token ownership fro=
m one<br>&gt; Bitcoin UTXO to another, do you generate a new UTXO for the r=
ecipient or do<br>&gt; you support the ability to &quot;teleport&quot; the =
tokens to an existing UTXO like how<br>&gt; RGB does it? If the latter, hav=
e you given consideration to timing issues<br>&gt; that might occur when so=
meone sends tokens to an existing UTXO that<br>&gt; simultaneously happens =
to get spent by the owner?<br><br>So for interactive transfers, the UTXOs g=
enerated as just the ones part of the<br>MIMO transaction. When sending via=
 the address format, a new non-dust output is<br>created which holds the ne=
w commitment, and uses an internal key provided by<br>the receiver, so only=
 they can move the UTXO. Admittedly, I&#39;m not familiar with<br>how the R=
GB &quot;teleport&quot; technique works, I checked out some slide=C2=A0deck=
s a while<br>back, but they were mostly about all the new components they w=
ere creating and<br>their milestone of 1 million lines of code. Can you poi=
nt me to a coherent<br>explanation of the technique? I&#39;d love to compar=
e/contrast so we can analyze<br>the diff tradeoffs being made here.<br><br>=
Thanks for an initial round of feedback/analysis, I&#39;ll be updating the =
draft<br>over the next few days to better spell things out and particularly=
 that<br>commitment/sighash uniqueness trait.<br><br>-- Laolu<br><br>[1]: <=
a href=3D"https://twitter.com/roasbeef/status/1330654936074371073?s=3D20&am=
p;t=3DfeV0kWAjJ6MTQlFm06tSxA" target=3D"_blank">https://twitter.com/roasbee=
f/status/1330654936074371073?s=3D20&amp;t=3DfeV0kWAjJ6MTQlFm06tSxA</a><br>[=
2]: <a href=3D"https://twitter.com/roasbeef/status/1330692571736117249?s=3D=
20&amp;t=3DfeV0kWAjJ6MTQlFm06tSxA" target=3D"_blank">https://twitter.com/ro=
asbeef/status/1330692571736117249?s=3D20&amp;t=3DfeV0kWAjJ6MTQlFm06tSxA</a>=
<br></div></div>
</blockquote></div>

--000000000000b5d66805dc4fa5d6--