public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
@ 2022-04-05 15:06 Olaoluwa Osuntokun
  2022-04-07 17:14 ` Ruben Somsen
       [not found] ` <CAO6oAq2nC9_0GdoOQbmX3Qt4OsSYzMVBy-vyGczwn1GhLHN2Kw@mail.gmail.com>
  0 siblings, 2 replies; 18+ messages in thread
From: Olaoluwa Osuntokun @ 2022-04-05 15:06 UTC (permalink / raw)
  To: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev, lightning-dev

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
@ 2022-04-05 20:23 vjudeu
  2022-04-06  0:43 ` ZmnSCPxj
  0 siblings, 1 reply; 18+ messages in thread
From: vjudeu @ 2022-04-05 20:23 UTC (permalink / raw)
  To: bitcoin-dev, laolu32

When I see more and more proposals like this, where things are commited to Taproot outputs, then I think we should start designing "miner-based commitments". If someone is going to make a Bitcoin transaction and add a commitment for zero cost, just by tweaking some Taproot public key, then it is a benefit for the network, because then it is possible to get more things with no additional bytes. Instead of doing "transaction-only", people can do "transaction+commitment" for the same cost, that use case is positive.

But if someone is going to make a Bitcoin transaction only to commit things, where in other case that person would make no transaction at all, then I think we should have some mechanism for "miner-based commitments" that would allow making commitments in a standardized way. We always have one coinbase transaction for each block, it is consensus rule. So, by tweaking single public key in the coinbase transaction, it is possible to fit all commitments in one tweaked key, and even make it logarithmic by forming a tree of commitments.

I think we cannot control user-based commitments, but maybe we should standardize miner-based commitments, for example to have a sorted merkle tree of commitments. Then, it would be possible to check if some commitment is a part of that tree or not (if it is always sorted, then it is present at some specified position or not, so by forming SPV-proof we can quickly prove, if some commitment is or is not a part of some miner Taproot commitment).

On 2022-04-05 15:06:03 user Olaoluwa Osuntokun <laolu32@gmail.com> 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



^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
@ 2022-04-11  0:30 Bram Cohen
  2022-04-11 18:21 ` Olaoluwa Osuntokun
  0 siblings, 1 reply; 18+ messages in thread
From: Bram Cohen @ 2022-04-11  0:30 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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

From: Olaoluwa Osuntokun <laolu32@gmail.com>

>
> > 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.
>

The TARO set of tradeoffs is fairly coherent but is subject to certain
limitations (modulo my understanding of it being off):

The witnesses for transactions need to be put into Bitcoin transactions
even though the Bitcoin layer doesn't understand them

There needs to be a constraint on Taro transactions which is understood by
the Bitcoin layer (which often/usually happens naturally because there's a
user signature but sometimes doesn't. It's a limitation)

Multiple Taro coins can't consolidate their value into a single output
because they only support a single linear history

Taro issuance is limited to a single event rather than potentially multiple
events over time subject to special per-asset rules.

This seems like a fairly logical approach (although my understanding of the
limitations/tradeoffs could be wrong, especially with regards to
consolidation). There's nothing wrong with a system having well documented
limitations, but I am puzzled by the announcement saying Taro assets are
'analogous with' colored coins. Taro assets are straightforwardly and
unambiguously colored coins and that isn't something to be ashamed of.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-11-07 13:51 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-05 15:06 [bitcoin-dev] Taro: A Taproot Asset Representation Overlay Olaoluwa Osuntokun
2022-04-07 17:14 ` Ruben Somsen
2022-04-07 19:11   ` [bitcoin-dev] [Lightning-dev] " Alex Schoof
2022-04-08 17:49     ` Olaoluwa Osuntokun
2022-04-08 17:48   ` [bitcoin-dev] " Olaoluwa Osuntokun
2022-04-10 16:51     ` Ruben Somsen
2022-04-11 19:51       ` Olaoluwa Osuntokun
2022-04-15 13:14         ` Ruben Somsen
2022-11-03  9:26       ` [bitcoin-dev] [Lightning-dev] " Johan Torås Halseth
2022-11-05  0:35         ` Olaoluwa Osuntokun
2022-11-07 13:51           ` Johan Torås Halseth
2022-04-16  2:43     ` [bitcoin-dev] " Olaoluwa Osuntokun
     [not found] ` <CAO6oAq2nC9_0GdoOQbmX3Qt4OsSYzMVBy-vyGczwn1GhLHN2Kw@mail.gmail.com>
2022-10-19  2:40   ` [bitcoin-dev] [Lightning-dev] " Olaoluwa Osuntokun
2022-04-05 20:23 [bitcoin-dev] " vjudeu
2022-04-06  0:43 ` ZmnSCPxj
2022-04-11  0:30 Bram Cohen
2022-04-11 18:21 ` Olaoluwa Osuntokun
2022-04-11 21:29   ` Bram Cohen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox