From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 203C4C0012; Thu, 7 Apr 2022 19:11:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id F20CC40999; Thu, 7 Apr 2022 19:11:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVgB31KKu9BG; Thu, 7 Apr 2022 19:11:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by smtp4.osuosl.org (Postfix) with ESMTPS id 0677A408AE; Thu, 7 Apr 2022 19:11:50 +0000 (UTC) Received: by mail-io1-xd35.google.com with SMTP id k25so7984899iok.8; Thu, 07 Apr 2022 12:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7NI9q80Rh7peFXN41UW/8BEtNH4CYHo/6icZTRBWqxE=; b=EZ6v0ZZwiUMuc4fOrNVu6KcWbr7tTsjwZdJK228lDw+dXXqpvWqaUlJ1ISmwabmVLB 1qV/eszg4FMi12ow+2MX8e2N9IUu8ZrSHnBafSyQWXkG9kqomoT+SMRfw7GD54PpOcRq Uvo56X4FLo/IGxjYqSaasw5xto8DI3woGo0XrI5tWn9vQ4RTu2oNHlK3G9aqKJBy0sKg d4g7zyRskYiBHYhxaz+ef/TyWjq0tWliQAqz31mLoMyyByeCfRLc/FEazvBDHITM7UCh NCYmpL4QCQzEYNk604IvYoyP7c6DLmZiOUnqiqbTilkW0YCTpex/bNwCoyCtNKGZcX7g KxMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7NI9q80Rh7peFXN41UW/8BEtNH4CYHo/6icZTRBWqxE=; b=D7Gs2Ua3ne/j7RJb0/l2/w8nLkfI8LvYgZvUxn6XqXS67Tzaqem9+SWmm4VAVizU24 7N04mHh6gkCpeSdPz9pkXnxLFydh/m4fY+y+oCN9jSPsR4X7ajfIVwMgnS+cw4GHRZsB x6xfXbQ3s8HXJSi3a+Zltr0L1q5OMS7d236jPVfPdJsc68xUCy73VjDZIH6ODKwi+nZL +B0///m2gDJeBaRjafcWdi50bXttOHGdRsq6MvOCpFoTjcLgSp10NJo5JcW8AjKIfPgt m/fWGeYM7baPoczgXSfLaE3cwD/klZdbTFLiiiJccWFApDNgBb5TYxBsyT4KA1yuTt+b mPew== X-Gm-Message-State: AOAM530CDkYmSPwQQuVr9/uEuLvHfkeCkGi1oHtPZc1Scco4hA3LrNGA xcIOqZXn6Z80L6vXtT+HCdk7TTfrS2GtnsmQfX3kLLOfKFc= X-Google-Smtp-Source: ABdhPJwwlMHDZoPaLPt797VIIOIQhKfIi18Cl7N+/uxBG1Q8H8ds9440XsY0nI7/DtT6DkIUmeMGI1P7+2kmePATyEY= X-Received: by 2002:a05:6602:2e10:b0:649:e2d4:3334 with SMTP id o16-20020a0566022e1000b00649e2d43334mr6836297iow.210.1649358709919; Thu, 07 Apr 2022 12:11:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Schoof Date: Thu, 7 Apr 2022 15:11:39 -0400 Message-ID: To: Ruben Somsen Content-Type: multipart/alternative; boundary="0000000000000316a105dc15400a" X-Mailman-Approved-At: Thu, 07 Apr 2022 19:44:14 +0000 Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 19:11:54 -0000 --0000000000000316a105dc15400a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-white= paper-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 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 f= ew > 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 insid= e > Taro, but she wants to make it conditional. Bob gets the Taro tokens if h= e > reveals a pre-image, while Alice can claim the tokens back after the > timelock expires (i.e. the minimum scripting requirements for HTLCs). Ali= ce > starts by locking up coins in a 2-of-2 multisig on the mainchain with som= e > 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 scri= pt > 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. Nonetheles= s, > 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 wan= ts > to send 4 of them to Dave and keep 1. There are two possible designs here= : > > a.) The token history remains separate =E2=80=93 Dave receives Alice's 2 = tokens, > Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice). > > b.) The token history gets merged =E2=80=93 Dave receives 4 tokens (linki= ng 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 mode= l > (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 i= s > 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 elemen= t > of four. This implies the location of the Taro tree inside the taproot tr= ee > 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 purpos= e > of the sparse merkle tree in your design? I suppose you want to be able t= o > 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 =E2=80=93 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 tha= t > simultaneously happens to get spent by the owner? > > In any case, I hope this email was useful. Feel free to reach out if I ca= n > 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 structure= d >> meta >> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tre= e >> 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). Tar= o >> 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 oth= er >> 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 an= d >> 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, an= d >> 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), whic= h >> 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.mediawi= ki >> * The Taro flat file proof format: >> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.media= wiki >> >> 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 > --=20 Alex Schoof --0000000000000316a105dc15400a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Laolu,

Really interesting protocol.= I'm not all the way through all of the docs yet, but had a few questio= ns/comments:=C2=A0
- The top-level doc (https://github.com/Roa= sbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks about embedding over= lay metadata in the taproot script tree. From my reading, it seems like wha= t gets committed is the root of the taro MS-SMT tree, while leaves of the t= ree itself are off-chain=C2=A0in a proof file. If that's the case, did = you look at other mechanisms to commit to a merkle root? For example, I bel= ieve mainstay[1] uses a pay-to-contract/bip175[2]-like scheme to commit sid= echain merkle roots to p2pkh/p2sh addresses with signature tweaks. Are ther= e 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 fi= le which is passed between users, where the receiver=C2=A0can 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 ke= ep track of asset lineages on behalf of users, which would be useful for li= ght clients of heavily-used asset types (so your mobile client doesnt=C2=A0= have to traverse the transfer lineage of some high-liquidity stablecoin or = something).=C2=A0

- Rubin made a good point above = about how something like a conditional transfer in a taro asset won't n= ecessarily 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=C2=A0+ some buffer. The thought being that I'm basically jus= t 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 clo= se to or less than the value of the bitcoin that's being used to do the= transfer.=C2=A0

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

- was this origi= nally named CMYK?=C2=A0

Thanks,

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






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 t= heir 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 fr= om getting split into tiny fragments.

The issue wi= th b.) is that you end up with a linked transaction graph, just like in Bit= coin. If you pick a random Bitcoin UTXO and try to trace it back to a coinb= ase, 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 equivale= nt to the amount of history that a recipient of a Taro token has to validat= e 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&= #39;s the best approach and to generally get a better idea of how it affect= s scaling. Also, the repeated sharing of history makes me skeptical about t= he privacy this protocol may provide. If large amounts of history moved thr= ough the hands of a large number of people, it wouldn't be very private= .

There's a third third smaller issue I want t= o point out, which is easily fixable and perhaps was just a typo. In your s= lides, you showed a screenshot of a taproot tree containing the Taro tree a= s the third element of four. This implies the location of the Taro tree ins= ide 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 o= wner of the commitment to show different histories to different people.

Finally, let me conclude with two questions. Could yo= u clarify the=C2=A0purpose of the=C2=A0sparse merkle tree in your design? I= suppose you want to be able to open a commitment and show it contains a ce= rtain asset without having to reveal any of the other assets and simultaneo= usly 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 =E2= =80=93 when transferring Taro token ownership from one Bitcoin UTXO to anot= her, do you generate a new UTXO for the recipient or do you support the abi= lity to "teleport" the tokens to an existing UTXO like how RGB do= es it? If the latter, have you given consideration to timing issues that mi= ght occur when someone sends tokens to an existing UTXO that simultaneously= happens to get spent by the owner?

In any case, I= =C2=A0hope this email was useful. Feel free to reach out if I can clarify a= nything.

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.linuxfoundatio= n.org> wrote:
Hi y'al= l,

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 Repr= esentation Overlay which
allows the issuance of normal and also collecti= ble 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 th= e properties of a merkle sum tree, with a sparse
merkle tree, enabling t= hings like easily verifiable asset supply proofs and
also efficient proo= fs 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
tr= ansfers are then embedded in a virtual/overlay transaction graph which uses= a
chain of asset witnesses to provably track the transfer of assets acr= oss
taproot outputs. Taro also has a scripting system, which allows for<= br>programmatic unlocking/transfer of assets. In the first version, the scr= ipting
system is actually a recursive instance of the Bitcoin Script Tap= root VM,
meaning anything that can be expressed in the latest version of= Script can be
expressed in the Taro scripting system. Future versions o= f 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 c= an be used to emulate the existing HTLC structure, which
allows for mult= i-hop transfers of Taro assets. Rather than modify the internal
network,= the protocol proposes to instead only recognize "assets at the edges&= quot;,
which means that only the sender+receiver actually need to know a= bout and
validate the assets. This deployment route means that we don= 9;t need to build up
an entirely new network and liquidity for each asse= t. Instead, all asset
transfers will utilize the Bitcoin backbone of the= Lightning Network, which
means that the internal routers just see Bitco= in transfers as normal, and don't
even know about assets at the edge= s. As a result, increased demand for
transfers of these assets as the ed= ges (say like a USD stablecoin), which in
will turn generate increased d= emand of LN capacity, result in more transfers, and
also more routing re= venue for the Bitcoin backbone nodes.

The set of BIPs are a multi-pa= rt suite, with the following breakdown:
=C2=A0* The main Taro protocol: = https://github.com/Roasbeef/bips/blob/bip-taro/bip-tar= o.mediawiki
=C2=A0* The MS-SMT structure: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki<= /a>
=C2=A0* The Taro VM: https://github.com/Roas= beef/bips/blob/bip-taro/bip-taro-vm.mediawiki
=C2=A0* The Taro addre= ss format: https://github.com/Roasbeef/bips/blob/= bip-taro/bip-taro-addr.mediawiki
=C2=A0* The Taro Universe concept: = https://github.com/Roasbeef/bips/blob/bip-tar= o/bip-taro-universe.mediawiki
=C2=A0* The Taro flat file proof forma= t: =C2=A0https://github.com/Roasbeef/bips/b= lob/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), a= ll the BIPs can be found above.

-- Laolu
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev


--


Alex Schoof
--0000000000000316a105dc15400a--