[bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- 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 --]

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Ruben Somsen]

[-- 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 --]

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Alex Schoof]

[-- Attachment #1: Type: text/plain, Size: 13963 bytes --]

Hey Laolu,

Really interesting protocol. I'm not all the way through all of the docs
yet, but had a few questions/comments:
- The top-level doc (
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks
about embedding overlay metadata in the taproot script tree. From my
reading, it seems like what gets committed is the root of the taro MS-SMT
tree, while leaves of the tree itself are off-chain in a proof file. If
that's the case, did you look at other mechanisms to commit to a merkle
root? For example, I believe mainstay[1] uses a
pay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to
p2pkh/p2sh addresses with signature tweaks. Are there other interesting (to
taro) spend-paths that need to be allowed that led to the taproot script
tree being particularly helpful?

- It appears that the transfer proofs are kept off-chain in another file
which is passed between users, where the receiver can validate the transfer
according to whatever semantics the taro-vm has at that moment and refuse
to credit the sender if the transfer breaks some business logic or
validation rules. This reminds me a lot of single-use-seals[3]. Is that the
right way to think about what's going on here? If it is, then it looks like
a Universe/Multiverse is an offload/aggregation mechanism that can keep
track of asset lineages on behalf of users, which would be useful for light
clients of heavily-used asset types (so your mobile client doesnt have to
traverse the transfer lineage of some high-liquidity stablecoin or
something).

- Rubin made a good point above about how something like a conditional
transfer in a taro asset won't necessarily cause the conditional bitcoin
transfer to fail. My first thought was to have the "carrier utxo" for a
taro asset be really small, like dust + some buffer. The thought being that
I'm basically just paying gas and if I lose `dust+buffer` amount of bitcoin
but not a lot of some token, then that's not great but not terrible. Where
it gets bad is if the value of the taro asset that you're trying to
transfer is close to or less than the value of the bitcoin that's being
used to do the transfer.

- There's been a lot of talk lately on the bitcoin-dev list about
covenants, and I wonder if some of those designs (specifically TLUV or CTV)
might be useful with Taro, to "lift" some of the taro conditions into
covenants that encumber the underlying bitcoin. I don't have a design or
anything, wondering if you've given this any thought.

- was this originally named CMYK?

Thanks,
Alex


[1]
https://cloudflare-ipfs.com/ipns/ipfs.commerceblock.com/commerceblock-whitepaper-mainstay.pdf
[2] https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki
[3] https://petertodd.org/2016/commitments-and-single-use-seals

On Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi Laolu,
>
> Nice work. This is an interesting protocol, in my opinion.
>
> Seeing as there's a large amount of overlap with RGB, a protocol which I
> have examined quite extensively, I believe some of the issues I uncovered
> in that project also apply here.
>
> The biggest issue revolves around the scripting expectations for this
> protocol. Taro is described as being able to have its own scripting
> capabilities that will initially be similar to Bitcoin and eventually be
> made to do more. I'm afraid this is fundamentally impossible. Conditional
> scripts (and thus most scripts that could potentially be of interest) won't
> be possible if the satisfaction of the condition is not recorded publicly
> on-chain.
>
> The core problem here is that you have two levels of scripting. At the
> Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the
> Taro level you have yet another script. This may seem similar at first
> glance to how taproot has a key path and a script path, but there are a few
> key differences. In taproot only one of the two needs to be satisfied,
> while here you need to satisfy both. Furthermore, the Taro script is not
> enforced by Bitcoin, meaning those who control the Bitcoin script can
> always choose to ignore the Taro script and destroy the Taro assets as a
> result.
>
> I'll describe an example. Imagine Alice wants to send Bob a payment inside
> Taro, but she wants to make it conditional. Bob gets the Taro tokens if he
> reveals a pre-image, while Alice can claim the tokens back after the
> timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice
> starts by locking up coins in a 2-of-2 multisig on the mainchain with some
> Taro tokens inside. She then gives Bob a pre-signed transaction that only
> requires him to reveal the pre-image in order to claim the tokens. The
> issue here is that from Bitcoin's perspective, you're giving Bob a valid
> transaction, regardless of whether he reveals the pre-image. If Bob
> maliciously broadcasts it without the pre-image, he will have destroyed
> your tokens.
>
> Of course this was a contrived example, as these conditions 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
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>


-- 


Alex Schoof

[-- Attachment #2: Type: text/html, Size: 16450 bytes --]

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 4474 bytes --]

(this might be a double post as I ran into the size limit)

Hi Alex,

Thanks for taking a look at things!

> If that's the case, did you look at other mechanisms to commit to a merkle
> root? For example, I believe mainstay[1] uses a
> pay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to
> p2pkh/p2sh addresses with signature tweaks. Are there other interesting
> (to taro) spend-paths that need to be allowed that led to the taproot
> script tree being particularly helpful?

I considered other approaches, but by relying on the existing taproot
commitment structure/derivation, Taro implementations are able to re-use
surrounding code/libraries, making a core implementation more compact.
Committing into the tapscript tree is also simpler than signature tweaks.
One nice trait about using the tapscript tree is that from a wallet's
perceptive, Taro just wants a particular opaque hash to be included in the
final tapscript tree. As a result, the wallet doesn't need to modify the way
they sign, or do key derivations or anything. In addition, using the
tapscript tree lets us separate the Bitcoin layer from the Taro layer as far
as scripts, and also enables easily verification of any sort of Script
mirroring between the layers that may be required for certain applications.

> This reminds me a lot of single-use-seals[3]. Is that the right way to
> think about what's going on here?

Yes a similar construct is used. I personally don't really like the
single-use-seals terminology, as I find it somewhat obtuse and trying to
bind the mechanics to the analogy/metaphor just makes it harder for people
to understand what's going on.

> If it is, then it looks like a Universe/Multiverse is an
> offload/aggregation mechanism that can keep track of asset lineages on
> behalf of users, which would be useful for light clients of heavily-used
> asset types (so your mobile client doesnt have to traverse the transfer
> lineage of some high-liquidity stablecoin or something).

So the provide a few different types of functionality:

 * A way to bootstrap genesis output provenance by maintaining a Universe
   which is just the set of asset issuance transactions (the Universe
MS-SMT is
   keyed by a prevOut at the lowest level). This can be done for several
   assets.

 * A way to collect+index a more complete view of the set of transfers
   related to assets. This can serve the basis for things like a block
   explorer for a single or several assets. Since the data structure is
   history independent, multiple explorers can publish their root hash which
   makes it easy to check that they have the same data, and a bisection
   protocol can be used to sync up distinct universe/multiverse instances.

 * A way to allow aggregation of transfers tied to a single to level UTXO
   chain, which would likely be used in cases like games where the actual
   game needs other servers or closed source functionality, but the game
   publisher wants the users to be able to prove ownership and also trade in
   game asset. This can be maintained by a single party, or a
   threshold/federation. The parties can't include invalid state transitions
   or proofs (can't forge the proper signature, etc).

> - There's been a lot of talk lately on the bitcoin-dev list about
> covenants, and I wonder if some of those designs (specifically TLUV or
> CTV) might be useful with Taro, to "lift" some of the taro conditions into
> covenants that encumber the underlying bitcoin. I don't have a design or
> anything, wondering if you've given this any thought.

Yep! I described a sketch of something like that using TLVU in my prior
reply to Rubin. At a high level, since Taro affect the tapscript root hash,
which affects the output key, by requiring a certain output key, or swapping
out the leaf elements, a covenant can further bind Taro rules without
needing to explicitly do validation/execution in Bitcoin script itself.

> My first thought was to have the "carrier utxo" for a taro asset be really
> small, like dust + some buffer.

Hmm, can you describe this in more detail? Do you mean an _extra_ UTXO, or
just mapping the Taro conditions as much as possible to the top-level
Bitcoin scripts?

> - was this originally named CMYK?

Maybe ;), a few versions were floating around before I published the current
draft, so some prior artifacts may still be floating around. Will do another
sweep to clean up anything else that was lingering.

-- Laolu

[-- Attachment #2: Type: text/html, Size: 4941 bytes --]

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- 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 --]

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Ruben Somsen]

[-- 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 --]

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- 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 --]

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Ruben Somsen]

[-- 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 --]

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Johan Torås Halseth]

[-- Attachment #1: Type: text/plain, Size: 16244 bytes --]

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 <rsomsen@gmail.com> wrote:

> Hi Laolu,
>
> >happy to hear that someone was actually able to extract enough details
> from the RGB devs/docs to be able to analyze it properly
>
> Actually, even though I eventually puzzled everything together, this did
> not go well for me either. There is a ton of documentation, but it's a maze
> of unhelpful details, and none of it clearly maps out the fundamental
> design. I was also disappointed by the poor response I received when asking
> questions, and I ended up getting chastised for helping others understand
> it and pointing out potential flaws[1][2][3].Given my experience, I think
> the project is not in great shape, so the decision to rebuild from scratch
> seems right to me.
>
> That said, in my opinion the above should not factor into the decision of
> whether RGB should be credited in the Taro documentation. The design
> clearly precedes (and seems to have inspired) Taro, so in my opinion this
> should be acknowledged. Also, the people that are responsible for the
> current shape of RGB aren't the people who originated the idea, so it would
> not be fair to the originators either (Peter Todd, Alekos Filini, Giacomo
> Zucco).
>
> >assets can be burnt if a user doesn't supply a valid witness
>
> I am in agreement with what you said, but it is not clear to me whether we
> are on the same page. What I tried to say was that it does not make sense
> to build scripting support into Taro, because you can't actually do
> anything interesting with it due to this limitation. The only type of smart
> contract you can build is one where you limit what the owner (as defined by
> Bitcoin's script) can do with their own Taro tokens, or else he will burn
> them – not very useful. Anything involving a conditional transfer of
> ownership to either A or B (i.e. any meaningful type of script) won't work.
> Do you see what I mean, or should I elaborate further?
>
> >TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transitions
> at the Bitcoin level, without Bitcoin explicitly needing to be aware
>
> That is conceptually quite interesting. So theoretically you could get
> Bitcoin covenants to enforce certain spending conditions on Taro assets.
> Not sure how practical that ends up being, but intriguing to consider.
>
> >asset issuer to do a "re-genesis"
>
> Yes, RGB suggested the same thing, and this can work under some
> circumstances, but note that this won't help for tokens that aim to have a
> publicly audited supply, as the proof that a token was legitimately
> re-issued is the history of the previous token (so you'd actually be making
> things worse, as now everyone has to verify it). And of course the idea
> also requires the issuer to be active, which may not always be the case.
>
> >I'm not familiar with how the RGB "teleport" technique works [...] Can
> you point me to a coherent explanation of the technique
>
> To my knowledge no good explanation exists. "Teleporting" is just what I
> thought was a good way of describing it. Basically, in your design when
> Alice wants to send a Taro token to Bob, Alice has to spend her own output,
> make a new output for Bob, and make a change output for herself. Inside the
> Taro tree you'll then point to the index of Bob's output in order to 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
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

[-- Attachment #2: Type: text/html, Size: 19610 bytes --]

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 4102 bytes --]

Hi Johan,

I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However, by the time
that transaction hits the chain, the UTXO may no longer exist. At that
point, what happens to the asset? Is it burned? Can you retry it again? Does
it go back to the sender?

As a concrete example, imagine I have a channel open, and give you an
address to "teleport" some additional assets to it. You take that addr, then
make a transaction to commit to the transfer. However, the block before you
commit to the transfer, my channel closes for w/e reason. As a result, when
the transaction committing to the UTXO (blinded or not), hits the chain, the
UTXO no longer exists. Alternatively, imagine the things happen in the
expected order, but then a re-org occurs, and my channel close is mined in a
block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
used as a serialization point, the scheme seems to lack a necessary total
ordering to ensure safety.

If we look at Taro's state transition model in contrast, everything is fully
bound to a single synchronization point: a normal Bitcoin transaction with
inputs consumed and outputs created. All transfers, just like Bitcoin
transactions, end up consuming assets from the set of inputs, and
re-creating them with a different distribution with the set of outputs. As a
result, Taro transfers inherit the same re-org safety traits as regular
Bitcoin transactions. It also isn't possible to send to something that won't
ultimately exist, as sends create new outputs just like Bitcoin
transactions.

Taro's state transition model also means anything you can do today with
Bitcoin/LN also apply. As an example, it would be possible for you to
withdrawn from your exchange into a Loop In address (on chain to off chain
swap), and have everything work as expected, with you topping off your
channel. Stuff like splicing, and other interactive transaction construction
schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.

Ignoring the ordering issue I mentioned above, I don't think this is a great
model for anchoring assets in channels either. With Taro, when you make the
channel, you know how many assets are committed since they're all committed
to in the funding output when the channel is created. However, let's say we
do teleporting instead: at which point would we recognize the new asset
"deposits"? What if we close before a pending deposits confirms, how can one
regain those funds? Once again you lose the serialization of events/actions
the blockchain provides. I think you'd also run into similar issues when you
start to think about how these would even be advertised on a hypothetical
gossip network.

I think one other drawback of the teleport model iiuc is that: it either
requires an OP_RETURN, or additional out of band synchronization to complete
the transfer. Since it needs to commit to w/e hash description of the
teleport, it either needs to use an OP_RETURN (so the receiver can see the
on chain action), or the sender needs to contact the receiver to initiate
the resolution of the transfer (details committed to in a change addr or
w/e).

With Taro, sending to an address creates an on-chain taproot output just
like sending to a P2TR address. The creation of the output directly creates
the new asset anchor/output as well, which allows the receiver to look for
that address on chain just like a normal on chain transaction. To 3rd party
observers, it just looks like a normal P2TR transfer. In order to finalize
the receipt of the asset, the receiver needs to obtain the relevant
provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
service keyed by the input outpoint and output index. In short, the send
process is fully async, with the sender and receiver using the blockchain
itself as a synchronization point like a normal Bitcoin wallet.

-- Laolu

[-- Attachment #2: Type: text/html, Size: 4418 bytes --]

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Johan Torås Halseth]

Hi Laolu,

Yeah, that is definitely the main downside, as Ruben also mentioned:
tokens are "burned" if they get sent to an already spent UTXO, and
there is no way to block those transfers.

And I do agree with your concern about losing the blockchain as the
main synchronization point, that seems indeed to be a prerequisite for
making the scheme safe in terms of re-orgs and asynchronicity.

I do think the scheme itself is sound though (maybe not off-chain, see
below): it prevents double spending and as long as the clients adhere
to the "rule" of not sending to a spent UTXO you'll be fine (if not
your tokens will be burned, the same way as if you don't satisfy the
Taro script when spending).

Thinking more about the examples you gave, I think you are right it
won't easily be compatible with LN channels though:
If you want to refill an existing channel with tokens, you need the
channel counterparties to start signing new commitments that include
spending the newly sent tokens. A problem arises however, if the
channel is force-closed with a pre-existing commitment from before the
token transfer took place. Since this commitment will be spending the
funding UTXO, but not the new tokens, the tokens will be burned. And
that seems to be harder to deal with (Eltoo style channels could be an
avenue to explore, if one could override the broadcasted commitment).

Tl;dr: I think you're right, the scheme is not compatible with LN.

- Johan


On Sat, Nov 5, 2022 at 1:36 AM Olaoluwa Osuntokun <laolu32@gmail.com> wrote:
>
> Hi Johan,
>
> I haven't really been able to find a precise technical explanation of the
> "utxo teleport" scheme, but after thinking about your example use cases a
> bit, I don't think the scheme is actually sound. Consider that the scheme
> attempts to target transmitting "ownership" to a UTXO. However, by the time
> that transaction hits the chain, the UTXO may no longer exist. At that
> point, what happens to the asset? Is it burned? Can you retry it again? Does
> it go back to the sender?
>
> As a concrete example, imagine I have a channel open, and give you an
> address to "teleport" some additional assets to it. You take that addr, then
> make a transaction to commit to the transfer. However, the block before you
> commit to the transfer, my channel closes for w/e reason. As a result, when
> the transaction committing to the UTXO (blinded or not), hits the chain, the
> UTXO no longer exists. Alternatively, imagine the things happen in the
> expected order, but then a re-org occurs, and my channel close is mined in a
> block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
> used as a serialization point, the scheme seems to lack a necessary total
> ordering to ensure safety.
>
> If we look at Taro's state transition model in contrast, everything is fully
> bound to a single synchronization point: a normal Bitcoin transaction with
> inputs consumed and outputs created. All transfers, just like Bitcoin
> transactions, end up consuming assets from the set of inputs, and
> re-creating them with a different distribution with the set of outputs. As a
> result, Taro transfers inherit the same re-org safety traits as regular
> Bitcoin transactions. It also isn't possible to send to something that won't
> ultimately exist, as sends create new outputs just like Bitcoin
> transactions.
>
> Taro's state transition model also means anything you can do today with
> Bitcoin/LN also apply. As an example, it would be possible for you to
> withdrawn from your exchange into a Loop In address (on chain to off chain
> swap), and have everything work as expected, with you topping off your
> channel. Stuff like splicing, and other interactive transaction construction
> schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.
>
> Ignoring the ordering issue I mentioned above, I don't think this is a great
> model for anchoring assets in channels either. With Taro, when you make the
> channel, you know how many assets are committed since they're all committed
> to in the funding output when the channel is created. However, let's say we
> do teleporting instead: at which point would we recognize the new asset
> "deposits"? What if we close before a pending deposits confirms, how can one
> regain those funds? Once again you lose the serialization of events/actions
> the blockchain provides. I think you'd also run into similar issues when you
> start to think about how these would even be advertised on a hypothetical
> gossip network.
>
> I think one other drawback of the teleport model iiuc is that: it either
> requires an OP_RETURN, or additional out of band synchronization to complete
> the transfer. Since it needs to commit to w/e hash description of the
> teleport, it either needs to use an OP_RETURN (so the receiver can see the
> on chain action), or the sender needs to contact the receiver to initiate
> the resolution of the transfer (details committed to in a change addr or
> w/e).
>
> With Taro, sending to an address creates an on-chain taproot output just
> like sending to a P2TR address. The creation of the output directly creates
> the new asset anchor/output as well, which allows the receiver to look for
> that address on chain just like a normal on chain transaction. To 3rd party
> observers, it just looks like a normal P2TR transfer. In order to finalize
> the receipt of the asset, the receiver needs to obtain the relevant
> provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
> service keyed by the input outpoint and output index. In short, the send
> process is fully async, with the sender and receiver using the blockchain
> itself as a synchronization point like a normal Bitcoin wallet.
>
> -- Laolu

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- 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 --]

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 8750 bytes --]

Hi Hiroki,

(inserting the bitcoin-dev mailing list as this question is mainly
concerning on-chain interaction)

Thanks for taking the time to really dig into things!

> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs without gaps from
> the genesis transaction of the asset to the current location

> It is necessary to prove and verify that “the UTXO has not changed” at
> that point.

Correct!

> As far as I can see, the specs don't mention it.

You're correct that today the main BIP draft focuses mainly on transfers [1]
to specify how exactly an asset moves from one output to another. The
requirement that a "no-op" state transition also be created/verified is an
implicit assumption in the current spec that we aim to remedy. The current
alpha code [2] is a bit ahead of the spec, but we aim to start to catch up
the spec, and also begin to add test vectors now that we have a working
implementation.

> The proofs for directly proving that a UTXO has not changed are its
> inclusion proof in the input asset tree and its inclusion and
> non-inclusion proofs in each of the output asset trees

Correct, the set of inclusion and non-inclusion proofs necessary for a valid
state transition are currently documented in `bip-taro-proof-file.md` [3].
We've also made a few updates to the proof file format to properly include a
field for the inclusion proof of a split asset's _root_ asset. This allows
verifiers to properly verify the authenticity of the split (root is in the
transaction, uniquely, which commits to the split, which has a proof
anchored in that spit root).

> Instead, it's better to set a constraint that no part of the asset tree
> except the explicitly changed UTXOs should change, and verify that.

Interesting, so rather than present/maintain a distinct state transition for
each asset unaffected, you propose that instead we present a _single_ proof
for all non-modified assets that shows that a sub-tree/branch is unchanged?
That's a very cool idea.

Generally we have a lot of low hanging fruits re optimizing the proof file
format itself. As an example, all assets in a tree will share the same
Bitcoin-level proof prefix (merkle proof and block header of the anchor
transaction), but the spec/implementation will currently duplicate those
values several times over for each asset. If we go down another level, then
the main inclusion proof for an asset ID tree is also duplicated for each
asset sharing that asset ID.

Restating things a bit: right now proofs are oriented from the PoV of an
asset leaf in question. Instead, if we zoom out a bit and orient them at the
_taproot output_ level, then we can remove a lot of redundant data in the
current proof format, then sort of "prune" the output level proof to
generate a proof for a single leaf.

-- Laolu

[1]:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki#asset-transfers
[2]: https://github.com/lightninglabs/taro
[3]:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki#specification

On Fri, Oct 7, 2022 at 2:33 AM Hiroki Gondo <hiroki.gondo@nayuta.co> wrote:

> Hi Laolu,
>
> I've read Taro's specs, but I'm afraid there's not enough verification of
> the provenance of the asset UTXOs.
>
> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs without gaps from
> the genesis transaction of the asset to the current location. At some point
> in the transaction, the target UTXO itself may not change (only changes to
> other assets or other UTXOs in the asset tree). It is necessary to prove
> and verify that “the UTXO has not changed” at that point. As far as I can
> see, the specs don't mention it.
>
> Without this validation, asset inflation (double spending) is possible. In
> a transaction, there is a UTXO in the input asset tree. If this UTXO does
> not change in this transaction, it will remain in the output asset tree.
> However, if a full copy of this UTXO is illicitly created in the asset tree
> of another output, the asset will be inflated (even duplicating the lowest
> MS-SMT entirely). Both UTXOs will arbitrarily claim to be the same as the
> input UTXO.
>
> The proofs for directly proving that a UTXO has not changed are its
> inclusion proof in the input asset tree and its inclusion and non-inclusion
> proofs in each of the output asset trees. However, generating these proofs
> for every unchanging UTXO present in the input asset tree when a
> transaction occurs may not be very practical. Instead, it's better to set a
> constraint that no part of the asset tree except the explicitly changed
> UTXOs should change, and verify that.
>
> Please let me know if I'm wrong or have overlooked any specs. Also, let me
> know if there's anything about this that hasn't been mentioned in the specs
> yet.
>
> –
> Hiroki Gondo
>
>
> 2022年4月6日(水) 0:06 Olaoluwa Osuntokun <laolu32@gmail.com>:
>
>> 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
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 10507 bytes --]