📅 Original date posted:2022-04-07
📝 Original message:
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 at 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 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
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220407/9dd3bd33/attachment-0001.html>;
Alex Schoof [ARCHIVE] /
npub1l2…t6swn
2023-06-09 13:05:45
in reply to nevent1q…ea2m
Author Public Key
npub1l2nulj0wpjdkjj2t6ajqcsxjvm8u4c42qzdgnsa7x6p9hzgqan7q9t6swnPublished at
2023-06-09 13:05:45Event JSON
{
"id": "b38d2c88b9d5ef965a2ba1b18c3e662bf48d596df00c2788e1932602822fe2bd",
"pubkey": "faa7cfc9ee0c9b69494bd7640c40d266cfcae2aa009a89c3be36825b8900ecfc",
"created_at": 1686315945,
"kind": 1,
"tags": [
[
"e",
"c1ac64ee992d18d7b8d932787daee67ad718f5f201a43906185ec5b7898eec50",
"",
"root"
],
[
"e",
"c7bfda6b13da2327416236522f8e7955f0d6763d07eea5019009f2481999aac7",
"",
"reply"
],
[
"p",
"c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0"
]
],
"content": "📅 Original date posted:2022-04-07\n📝 Original message:\nHey Laolu,\n\nReally interesting protocol. I'm not all the way through all of the docs\nyet, but had a few questions/comments:\n- The top-level doc (\nhttps://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks\nabout embedding overlay metadata in the taproot script tree. From my\nreading, it seems like what gets committed is the root of the taro MS-SMT\ntree, while leaves of the tree itself are off-chain in a proof file. If\nthat's the case, did you look at other mechanisms to commit to a merkle\nroot? For example, I believe mainstay[1] uses a\npay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to\np2pkh/p2sh addresses with signature tweaks. Are there other interesting (to\ntaro) spend-paths that need to be allowed that led to the taproot script\ntree being particularly helpful?\n\n- It appears that the transfer proofs are kept off-chain in another file\nwhich is passed between users, where the receiver can validate the transfer\naccording to whatever semantics the taro-vm has at that moment and refuse\nto credit the sender if the transfer breaks some business logic or\nvalidation rules. This reminds me a lot of single-use-seals[3]. Is that the\nright way to think about what's going on here? If it is, then it looks like\na Universe/Multiverse is an offload/aggregation mechanism that can keep\ntrack of asset lineages on behalf of users, which would be useful for light\nclients of heavily-used asset types (so your mobile client doesnt have to\ntraverse the transfer lineage of some high-liquidity stablecoin or\nsomething).\n\n- Rubin made a good point above about how something like a conditional\ntransfer in a taro asset won't necessarily cause the conditional bitcoin\ntransfer to fail. My first thought was to have the \"carrier utxo\" for a\ntaro asset be really small, like dust + some buffer. The thought being that\nI'm basically just paying gas and if I lose `dust+buffer` amount of bitcoin\nbut not a lot of some token, then that's not great but not terrible. Where\nit gets bad is if the value of the taro asset that you're trying to\ntransfer is close to or less than the value of the bitcoin that's being\nused to do the transfer.\n\n- There's been a lot of talk lately on the bitcoin-dev list about\ncovenants, and I wonder if some of those designs (specifically TLUV or CTV)\nmight be useful with Taro, to \"lift\" some of the taro conditions into\ncovenants that encumber the underlying bitcoin. I don't have a design or\nanything, wondering if you've given this any thought.\n\n- was this originally named CMYK?\n\nThanks,\nAlex\n\n\n[1]\nhttps://cloudflare-ipfs.com/ipns/ipfs.commerceblock.com/commerceblock-whitepaper-mainstay.pdf\n[2] https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki\n[3] https://petertodd.org/2016/commitments-and-single-use-seals\n\nOn Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen \u003crsomsen at gmail.com\u003e wrote:\n\n\u003e Hi Laolu,\n\u003e\n\u003e Nice work. This is an interesting protocol, in my opinion.\n\u003e\n\u003e Seeing as there's a large amount of overlap with RGB, a protocol which I\n\u003e have examined quite extensively, I believe some of the issues I uncovered\n\u003e in that project also apply here.\n\u003e\n\u003e The biggest issue revolves around the scripting expectations for this\n\u003e protocol. Taro is described as being able to have its own scripting\n\u003e capabilities that will initially be similar to Bitcoin and eventually be\n\u003e made to do more. I'm afraid this is fundamentally impossible. Conditional\n\u003e scripts (and thus most scripts that could potentially be of interest) won't\n\u003e be possible if the satisfaction of the condition is not recorded publicly\n\u003e on-chain.\n\u003e\n\u003e The core problem here is that you have two levels of scripting. At the\n\u003e Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the\n\u003e Taro level you have yet another script. This may seem similar at first\n\u003e glance to how taproot has a key path and a script path, but there are a few\n\u003e key differences. In taproot only one of the two needs to be satisfied,\n\u003e while here you need to satisfy both. Furthermore, the Taro script is not\n\u003e enforced by Bitcoin, meaning those who control the Bitcoin script can\n\u003e always choose to ignore the Taro script and destroy the Taro assets as a\n\u003e result.\n\u003e\n\u003e I'll describe an example. Imagine Alice wants to send Bob a payment inside\n\u003e Taro, but she wants to make it conditional. Bob gets the Taro tokens if he\n\u003e reveals a pre-image, while Alice can claim the tokens back after the\n\u003e timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice\n\u003e starts by locking up coins in a 2-of-2 multisig on the mainchain with some\n\u003e Taro tokens inside. She then gives Bob a pre-signed transaction that only\n\u003e requires him to reveal the pre-image in order to claim the tokens. The\n\u003e issue here is that from Bitcoin's perspective, you're giving Bob a valid\n\u003e transaction, regardless of whether he reveals the pre-image. If Bob\n\u003e maliciously broadcasts it without the pre-image, he will have destroyed\n\u003e your tokens.\n\u003e\n\u003e Of course this was a contrived example, as these conditions could simply\n\u003e take place entirely in Bitcoin script, but it demonstrates that Taro script\n\u003e fundamentally cannot handle conditional payments, which is the basis for\n\u003e any meaningful script other than self-encumbering covenants (i.e. if you\n\u003e send your Taro tokens in any way other than specified, the tokens will be\n\u003e destroyed). Luckily this has no effect on whether Taro can function over\n\u003e Lightning, because solely relying on Bitcoin's scripting capabilities\n\u003e should be sufficient for that use case.\n\u003e\n\u003e As a side note, it may be worth pointing out that it *is* possible to\n\u003e create conditional payments if the satisfaction of the condition is\n\u003e recorded publicly on the mainchain (e.g. in an op_return), making it sort\n\u003e of a hybrid on-chain/off-chain model, but it would increase complexity\n\u003e considerably. I can explain this model in more detail, if it happens to\n\u003e interest you.\n\u003e\n\u003e Now there's a second issue I want to bring up, but unfortunately my\n\u003e understanding of how exactly you made assets divisible is not complete\n\u003e enough to know how this problem might have manifested in Taro. Nonetheless,\n\u003e I'll try to describe it.\n\u003e\n\u003e One of the core concepts of Taro/RGB is that the sender of the token has\n\u003e to reveal the history to the recipient. In case of an NFT the history is\n\u003e simply every prior owner and grows linearly, but in the case of fungible\n\u003e tokens things are more complicated. Let's say Carol receives 2 fungible\n\u003e Taro tokens from Alice and 3 fungible Taro tokens from Bob. Now Carol wants\n\u003e to send 4 of them to Dave and keep 1. There are two possible designs here:\n\u003e\n\u003e a.) The token history remains separate – Dave receives Alice's 2 tokens,\n\u003e Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice).\n\u003e\n\u003e b.) The token history gets merged – Dave receives 4 tokens (linking the\n\u003e new output with both Alice and Bob's history).\n\u003e\n\u003e The issue with a.) is that you're only ever fragmenting tokens, so\n\u003e eventually you end up with lots of tiny but separate amounts. This will\n\u003e cause making large payments to involve sending lots of tokens, each with\n\u003e their own history. Under this model, I suspect the fixed value token model\n\u003e (e.g. 1, 2, 4, 8) might be preferable, as this prevents the entire supply\n\u003e from getting split into tiny fragments.\n\u003e\n\u003e The issue with b.) is that you end up with a linked transaction graph,\n\u003e just like in Bitcoin. If you pick a random Bitcoin UTXO and try to trace it\n\u003e back to a coinbase, you'll quickly find that it could have come from many\n\u003e of them. The graph that you'd traverse to get to all of these coinbases is\n\u003e equivalent to the amount of history that a recipient of a Taro token has to\n\u003e validate in order to accept it, which I suspect quickly becomes a\n\u003e bottleneck that is not unlike that of a regular blockchain.\n\u003e\n\u003e It'd probably be wise to make a model of the potential transaction flow,\n\u003e and simulate how it affects the size of the history in order to determine\n\u003e what's the best approach and to generally get a better idea of how it\n\u003e affects scaling. Also, the repeated sharing of history makes me skeptical\n\u003e about the privacy this protocol may provide. If large amounts of history\n\u003e moved through the hands of a large number of people, it wouldn't be very\n\u003e private.\n\u003e\n\u003e There's a third third smaller issue I want to point out, which is easily\n\u003e fixable and perhaps was just a typo. In your slides, you showed a\n\u003e screenshot of a taproot tree containing the Taro tree as the third element\n\u003e of four. This implies the location of the Taro tree inside the taproot tree\n\u003e is not fixed. What needs to be prevented here is that a taproot tree\n\u003e contains more than one Taro tree, as that would enable the owner of the\n\u003e commitment to show different histories to different people.\n\u003e\n\u003e Finally, let me conclude with two questions. Could you clarify the purpose\n\u003e of the sparse merkle tree in your design? I suppose you want to be able to\n\u003e open a commitment and show it contains a certain asset without having to\n\u003e reveal any of the other assets and simultaneously guarantee that you\n\u003e haven't committed to the same asset twice (i.e. the SMT guarantees each\n\u003e asset gets a specific location in the tree)? Or is there another reason?\n\u003e\n\u003e And the second question – when transferring Taro token ownership from one\n\u003e Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do\n\u003e you support the ability to \"teleport\" the tokens to an existing UTXO like\n\u003e how RGB does it? If the latter, have you given consideration to timing\n\u003e issues that might occur when someone sends tokens to an existing UTXO that\n\u003e simultaneously happens to get spent by the owner?\n\u003e\n\u003e In any case, I hope this email was useful. Feel free to reach out if I can\n\u003e clarify anything.\n\u003e\n\u003e Good luck with the protocol.\n\u003e\n\u003e Best regards,\n\u003e Ruben\n\u003e\n\u003e On Tue, Apr 5, 2022 at 5:06 PM Olaoluwa Osuntokun via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hi y'all,\n\u003e\u003e\n\u003e\u003e I'm excited to publicly publish a new protocol I've been working on over\n\u003e\u003e the\n\u003e\u003e past few months: Taro. Taro is a Taproot Asset Representation Overlay\n\u003e\u003e which\n\u003e\u003e allows the issuance of normal and also collectible assets on the main\n\u003e\u003e Bitcoin\n\u003e\u003e chain. Taro uses the Taproot script tree to commit extra asset structured\n\u003e\u003e meta\n\u003e\u003e data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree\n\u003e\u003e or\n\u003e\u003e MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a\n\u003e\u003e sparse\n\u003e\u003e merkle tree, enabling things like easily verifiable asset supply proofs\n\u003e\u003e and\n\u003e\u003e also efficient proofs of non existence (eg: you prove to me you're no\n\u003e\u003e longer\n\u003e\u003e committing to the 1-of-1 holographic beefzard card during our swap). Taro\n\u003e\u003e asset\n\u003e\u003e transfers are then embedded in a virtual/overlay transaction graph which\n\u003e\u003e uses a\n\u003e\u003e chain of asset witnesses to provably track the transfer of assets across\n\u003e\u003e taproot outputs. Taro also has a scripting system, which allows for\n\u003e\u003e programmatic unlocking/transfer of assets. In the first version, the\n\u003e\u003e scripting\n\u003e\u003e system is actually a recursive instance of the Bitcoin Script Taproot VM,\n\u003e\u003e meaning anything that can be expressed in the latest version of Script\n\u003e\u003e can be\n\u003e\u003e expressed in the Taro scripting system. Future versions of the scripting\n\u003e\u003e system\n\u003e\u003e can introduce new functionality on the Taro layer, like covenants or other\n\u003e\u003e updates.\n\u003e\u003e\n\u003e\u003e The Taro design also supports integration with the Lightning Network\n\u003e\u003e (BOLTs) as\n\u003e\u003e the scripting system can be used to emulate the existing HTLC structure,\n\u003e\u003e which\n\u003e\u003e allows for multi-hop transfers of Taro assets. Rather than modify the\n\u003e\u003e internal\n\u003e\u003e network, the protocol proposes to instead only recognize \"assets at the\n\u003e\u003e edges\",\n\u003e\u003e which means that only the sender+receiver actually need to know about and\n\u003e\u003e validate the assets. This deployment route means that we don't need to\n\u003e\u003e build up\n\u003e\u003e an entirely new network and liquidity for each asset. Instead, all asset\n\u003e\u003e transfers will utilize the Bitcoin backbone of the Lightning Network,\n\u003e\u003e which\n\u003e\u003e means that the internal routers just see Bitcoin transfers as normal, and\n\u003e\u003e don't\n\u003e\u003e even know about assets at the edges. As a result, increased demand for\n\u003e\u003e transfers of these assets as the edges (say like a USD stablecoin), which\n\u003e\u003e in\n\u003e\u003e will turn generate increased demand of LN capacity, result in more\n\u003e\u003e transfers, and\n\u003e\u003e also more routing revenue for the Bitcoin backbone nodes.\n\u003e\u003e\n\u003e\u003e The set of BIPs are a multi-part suite, with the following breakdown:\n\u003e\u003e * The main Taro protocol:\n\u003e\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki\n\u003e\u003e * The MS-SMT structure:\n\u003e\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki\n\u003e\u003e * The Taro VM:\n\u003e\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki\n\u003e\u003e * The Taro address format:\n\u003e\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki\n\u003e\u003e * The Taro Universe concept:\n\u003e\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki\n\u003e\u003e * The Taro flat file proof format:\n\u003e\u003e https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki\n\u003e\u003e\n\u003e\u003e Rather than post them all in line (as the text wouldn't fit in the\n\u003e\u003e allowed size\n\u003e\u003e limit), all the BIPs can be found above.\n\u003e\u003e\n\u003e\u003e -- Laolu\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\n\n-- \n\n\nAlex Schoof\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220407/9dd3bd33/attachment-0001.html\u003e",
"sig": "785f459d72c37f020c4eaa8299ae482de5e2558c4b2ff8c7a6fceef729e05894d477e9cf683e073cb38945cd9f7612f8274ac365672b2669eaed447f6d95d724"
}