Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: bitcoin-dev@lists.linuxfoundation.org,laolu32@gmail.com
Date: Tue, 05 Apr 2022 22:23:05 +0200
Message-Id: <160141998-7e37e8b4e29d41a79eddfe20e9b8c75f@pmq4v.m5r2.onet>
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Precedence: list

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 commit=
ments". If someone is going to make a Bitcoin transaction and add a commitm=
ent for zero cost, just by tweaking some Taproot public key, then it is a b=
enefit for the network, because then it is possible to get more things with=
 no additional bytes. Instead of doing "transaction-only", people can do "t=
ransaction+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 woul=
d allow making commitments in a standardized way. We always have one coinba=
se transaction for each block, it is consensus rule. So, by tweaking single=
 public key in the coinbase transaction, it is possible to fit all commitme=
nts in one tweaked key, and even make it logarithmic by forming a tree of c=
ommitments.

I think we cannot control user-based commitments, but maybe we should stand=
ardize 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 p=
art 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, i=
f 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 th=
e past few months: Taro. Taro is a Taproot Asset Representation Overlay whi=
ch allows the issuance of normal and also collectible assets on the main Bi=
tcoin chain. Taro uses the Taproot script tree to commit extra asset struct=
ured meta data based on a hybrid merkle tree I call a Merkle Sum Sparse Mer=
kle 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 su=
pply 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 tra=
nsaction 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 Bitco=
in Script Taproot VM, meaning anything that can be expressed in the latest =
version of Script can be expressed in the Taro scripting system. Future ver=
sions of the scripting system can introduce new functionality on the Taro l=
ayer, 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 structur=
e, which allows for multi-hop transfers of Taro assets. Rather than modify =
the internal network, the protocol proposes to instead only recognize "asse=
ts at the edges", which means that only the sender+receiver actually need t=
o know about and validate the assets. This deployment route means that we d=
on'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 Ligh=
tning Network, which means that the internal routers just see Bitcoin trans=
fers 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 US=
D stablecoin), which in will turn generate increased demand of LN capacity,=
 result in more transfers, and also more routing revenue for the Bitcoin ba=
ckbone 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/b=
ip-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-tar=
o/bip-taro-universe.mediawiki
 * The Taro flat file proof format: https://github.com/Roasbeef/bips/blob/b=
ip-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