📅 Original date posted:2022-04-07
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220407/88044966/attachment.html>;
Ruben Somsen [ARCHIVE] /
npub1cn…qyeq0
2023-06-09 13:05:44
in reply to nevent1q…mhzl
Author Public Key
npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0Published at
2023-06-09 13:05:44Event JSON
{
"id": "c7bfda6b13da2327416236522f8e7955f0d6763d07eea5019009f2481999aac7",
"pubkey": "c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0",
"created_at": 1686315944,
"kind": 1,
"tags": [
[
"e",
"c1ac64ee992d18d7b8d932787daee67ad718f5f201a43906185ec5b7898eec50",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2022-04-07\n📝 Original message:\nHi Laolu,\n\nNice work. This is an interesting protocol, in my opinion.\n\nSeeing as there's a large amount of overlap with RGB, a protocol which I\nhave examined quite extensively, I believe some of the issues I uncovered\nin that project also apply here.\n\nThe biggest issue revolves around the scripting expectations for this\nprotocol. Taro is described as being able to have its own scripting\ncapabilities that will initially be similar to Bitcoin and eventually be\nmade to do more. I'm afraid this is fundamentally impossible. Conditional\nscripts (and thus most scripts that could potentially be of interest) won't\nbe possible if the satisfaction of the condition is not recorded publicly\non-chain.\n\nThe core problem here is that you have two levels of scripting. At the\nBitcoin level the UTXO is encumbered by the Bitcoin script, then at the\nTaro level you have yet another script. This may seem similar at first\nglance to how taproot has a key path and a script path, but there are a few\nkey differences. In taproot only one of the two needs to be satisfied,\nwhile here you need to satisfy both. Furthermore, the Taro script is not\nenforced by Bitcoin, meaning those who control the Bitcoin script can\nalways choose to ignore the Taro script and destroy the Taro assets as a\nresult.\n\nI'll describe an example. Imagine Alice wants to send Bob a payment inside\nTaro, but she wants to make it conditional. Bob gets the Taro tokens if he\nreveals a pre-image, while Alice can claim the tokens back after the\ntimelock expires (i.e. the minimum scripting requirements for HTLCs). Alice\nstarts by locking up coins in a 2-of-2 multisig on the mainchain with some\nTaro tokens inside. She then gives Bob a pre-signed transaction that only\nrequires him to reveal the pre-image in order to claim the tokens. The\nissue here is that from Bitcoin's perspective, you're giving Bob a valid\ntransaction, regardless of whether he reveals the pre-image. If Bob\nmaliciously broadcasts it without the pre-image, he will have destroyed\nyour tokens.\n\nOf course this was a contrived example, as these conditions could simply\ntake place entirely in Bitcoin script, but it demonstrates that Taro script\nfundamentally cannot handle conditional payments, which is the basis for\nany meaningful script other than self-encumbering covenants (i.e. if you\nsend your Taro tokens in any way other than specified, the tokens will be\ndestroyed). Luckily this has no effect on whether Taro can function over\nLightning, because solely relying on Bitcoin's scripting capabilities\nshould be sufficient for that use case.\n\nAs a side note, it may be worth pointing out that it *is* possible to\ncreate conditional payments if the satisfaction of the condition is\nrecorded publicly on the mainchain (e.g. in an op_return), making it sort\nof a hybrid on-chain/off-chain model, but it would increase complexity\nconsiderably. I can explain this model in more detail, if it happens to\ninterest you.\n\nNow there's a second issue I want to bring up, but unfortunately my\nunderstanding of how exactly you made assets divisible is not complete\nenough to know how this problem might have manifested in Taro. Nonetheless,\nI'll try to describe it.\n\nOne of the core concepts of Taro/RGB is that the sender of the token has to\nreveal the history to the recipient. In case of an NFT the history is\nsimply every prior owner and grows linearly, but in the case of fungible\ntokens things are more complicated. Let's say Carol receives 2 fungible\nTaro tokens from Alice and 3 fungible Taro tokens from Bob. Now Carol wants\nto send 4 of them to Dave and keep 1. There are two possible designs here:\n\na.) The token history remains separate – Dave receives Alice's 2 tokens,\nBob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice).\n\nb.) The token history gets merged – Dave receives 4 tokens (linking the new\noutput with both Alice and Bob's history).\n\nThe issue with a.) is that you're only ever fragmenting tokens, so\neventually you end up with lots of tiny but separate amounts. This will\ncause making large payments to involve sending lots of tokens, each with\ntheir own history. Under this model, I suspect the fixed value token model\n(e.g. 1, 2, 4, 8) might be preferable, as this prevents the entire supply\nfrom getting split into tiny fragments.\n\nThe issue with b.) is that you end up with a linked transaction graph, just\nlike in Bitcoin. If you pick a random Bitcoin UTXO and try to trace it back\nto a coinbase, you'll quickly find that it could have come from many of\nthem. The graph that you'd traverse to get to all of these coinbases is\nequivalent to the amount of history that a recipient of a Taro token has to\nvalidate in order to accept it, which I suspect quickly becomes a\nbottleneck that is not unlike that of a regular blockchain.\n\nIt'd probably be wise to make a model of the potential transaction flow,\nand simulate how it affects the size of the history in order to determine\nwhat's the best approach and to generally get a better idea of how it\naffects scaling. Also, the repeated sharing of history makes me skeptical\nabout the privacy this protocol may provide. If large amounts of history\nmoved through the hands of a large number of people, it wouldn't be very\nprivate.\n\nThere's a third third smaller issue I want to point out, which is easily\nfixable and perhaps was just a typo. In your slides, you showed a\nscreenshot of a taproot tree containing the Taro tree as the third element\nof four. This implies the location of the Taro tree inside the taproot tree\nis not fixed. What needs to be prevented here is that a taproot tree\ncontains more than one Taro tree, as that would enable the owner of the\ncommitment to show different histories to different people.\n\nFinally, let me conclude with two questions. Could you clarify the purpose\nof the sparse merkle tree in your design? I suppose you want to be able to\nopen a commitment and show it contains a certain asset without having to\nreveal any of the other assets and simultaneously guarantee that you\nhaven't committed to the same asset twice (i.e. the SMT guarantees each\nasset gets a specific location in the tree)? Or is there another reason?\n\nAnd the second question – when transferring Taro token ownership from one\nBitcoin UTXO to another, do you generate a new UTXO for the recipient or do\nyou support the ability to \"teleport\" the tokens to an existing UTXO like\nhow RGB does it? If the latter, have you given consideration to timing\nissues that might occur when someone sends tokens to an existing UTXO that\nsimultaneously happens to get spent by the owner?\n\nIn any case, I hope this email was useful. Feel free to reach out if I can\nclarify anything.\n\nGood luck with the protocol.\n\nBest regards,\nRuben\n\nOn Tue, Apr 5, 2022 at 5:06 PM Olaoluwa Osuntokun via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi y'all,\n\u003e\n\u003e I'm excited to publicly publish a new protocol I've been working on over\n\u003e the\n\u003e past few months: Taro. Taro is a Taproot Asset Representation Overlay which\n\u003e allows the issuance of normal and also collectible assets on the main\n\u003e Bitcoin\n\u003e chain. Taro uses the Taproot script tree to commit extra asset structured\n\u003e meta\n\u003e data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree\n\u003e or\n\u003e MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a\n\u003e sparse\n\u003e merkle tree, enabling things like easily verifiable asset supply proofs and\n\u003e also efficient proofs of non existence (eg: you prove to me you're no\n\u003e longer\n\u003e committing to the 1-of-1 holographic beefzard card during our swap). Taro\n\u003e asset\n\u003e transfers are then embedded in a virtual/overlay transaction graph which\n\u003e uses a\n\u003e chain of asset witnesses to provably track the transfer of assets across\n\u003e taproot outputs. Taro also has a scripting system, which allows for\n\u003e programmatic unlocking/transfer of assets. In the first version, the\n\u003e scripting\n\u003e system is actually a recursive instance of the Bitcoin Script Taproot VM,\n\u003e meaning anything that can be expressed in the latest version of Script can\n\u003e be\n\u003e expressed in the Taro scripting system. Future versions of the scripting\n\u003e system\n\u003e can introduce new functionality on the Taro layer, like covenants or other\n\u003e updates.\n\u003e\n\u003e The Taro design also supports integration with the Lightning Network\n\u003e (BOLTs) as\n\u003e the scripting system can be used to emulate the existing HTLC structure,\n\u003e which\n\u003e allows for multi-hop transfers of Taro assets. Rather than modify the\n\u003e internal\n\u003e network, the protocol proposes to instead only recognize \"assets at the\n\u003e edges\",\n\u003e which means that only the sender+receiver actually need to know about and\n\u003e validate the assets. This deployment route means that we don't need to\n\u003e build up\n\u003e an entirely new network and liquidity for each asset. Instead, all asset\n\u003e transfers will utilize the Bitcoin backbone of the Lightning Network, which\n\u003e means that the internal routers just see Bitcoin transfers as normal, and\n\u003e don't\n\u003e even know about assets at the edges. As a result, increased demand for\n\u003e transfers of these assets as the edges (say like a USD stablecoin), which\n\u003e in\n\u003e will turn generate increased demand of LN capacity, result in more\n\u003e transfers, and\n\u003e also more routing revenue for the Bitcoin backbone nodes.\n\u003e\n\u003e The set of BIPs are a multi-part suite, with the following breakdown:\n\u003e * The main Taro protocol:\n\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki\n\u003e * The MS-SMT structure:\n\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki\n\u003e * The Taro VM:\n\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki\n\u003e * The Taro address format:\n\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki\n\u003e * The Taro Universe concept:\n\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki\n\u003e * The Taro flat file proof format:\n\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki\n\u003e\n\u003e Rather than post them all in line (as the text wouldn't fit in the allowed\n\u003e size\n\u003e limit), all the BIPs can be found above.\n\u003e\n\u003e -- Laolu\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220407/88044966/attachment.html\u003e",
"sig": "2ba270bec94499f27d802f3e62fe7863381e65378f50b4926a9a178458bc48b7799be0c6b264b2154a2d1a486f1a6faabd735181bcb3e0abf54b5516e3702d9c"
}