path: root/41/1055ffe38e906bcab1768d3cfe1f6f3e809cf9

Return-Path: <laolu32@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 632E1C0012;
 Tue,  5 Apr 2022 15:06:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4181D4161A;
 Tue,  5 Apr 2022 15:06:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.448
X-Spam-Level: 
X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 cXJf956K3dxd; Tue,  5 Apr 2022 15:06:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [IPv6:2a00:1450:4864:20::330])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 926AA415AF;
 Tue,  5 Apr 2022 15:06:16 +0000 (UTC)
Received: by mail-wm1-x330.google.com with SMTP id r64so8167548wmr.4;
 Tue, 05 Apr 2022 08:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=g/4wkeQXhxhSzGsEHFKsMtYeM8KF2Vlsjg97GRTJbBk=;
 b=hNGNDa6qkhx2YZzOSuB4ycA1JRJ19b2pFlwG4xzmWf/+CYH9z+ezyojgpgOfEJ9NIr
 VF+X+Nt+I1qtKZKhDBcTAHoiPxAPCO6tFSNbLniZXG0RfHRPUtj3vpkxevAXAKNbhvW8
 k8mu8ArXUqP1tSolrb8sGVBAKtegclHUT0pa556vOevt70L7Jlf80tzuI4mMrxkJwCY7
 XW2xV6G5SDyOJIlvOnsB/mbzqHqHpZ0tPqNsOmZ7UR1GY/eKKgYKgYuX9fAqUf927X/c
 xWK6N6xErtzNqQH2E7Vez+00p2tg3cUQ7bKoyPzHihVAuc7hyt6+hgQuXdtRWIsMBk1X
 xwbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=g/4wkeQXhxhSzGsEHFKsMtYeM8KF2Vlsjg97GRTJbBk=;
 b=D48qG1pXWe/iDgvmEyjy5wnn/ruNFToA4Uu1R0pMzBpREAq5kE2ylbh2wqdxd6EnO/
 ol1WLWrKN8YUXVjPg+7I4B7w/UIM5YdP5Chn9Bw0Xq7xol/ZmCMHphrydIlDaQNWF5pk
 z0PsMLSFg1mVJg7jJLx043e6U1Flv8SOoGFC8QtEsOK/uVxlwZ5mSWpVWEeoY9+u+vDl
 4fTSa0/THLW4RxEsJukw9fZcPrJ7x6oTpmEerAGu2QSHNY79YalYf+KsU9D9bxv7TbET
 gAggcWpenbmSdMw4I4C42OE2/XMS8VA+EGO22gG2WZRlx7zBDo91t757cdI9bcTJyC4f
 Rn+g==
X-Gm-Message-State: AOAM530+lvSFk5z8VFGepzBVDd+5ezBzb09VPEfyuwYuoZZo4a+6+iHr
 L2ohh7zjIQoNDw/HqFmTHj7P2ksI1RCUQS05T7yHJ9CWSRk=
X-Google-Smtp-Source: ABdhPJzgExsUk2LWuhLPB5gnEjAYVbmvGkkySx8o0JAW4LIopJvuxOD8IEHrI/4tdd5bjmlScq/NZbl5td98H5yB4fw=
X-Received: by 2002:a05:600c:26d4:b0:38e:7b79:1095 with SMTP id
 20-20020a05600c26d400b0038e7b791095mr3627996wmv.95.1649171174249; Tue, 05 Apr
 2022 08:06:14 -0700 (PDT)
MIME-Version: 1.0
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 5 Apr 2022 11:06:03 -0400
Message-ID: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com>
To: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
 <bitcoin-dev@lists.linuxfoundation.org>, 
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000003d9d405dbe9968b"
Subject: [bitcoin-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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2022 15:06:18 -0000

--00000000000003d9d405dbe9968b
Content-Type: text/plain; charset="UTF-8"

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

--00000000000003d9d405dbe9968b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi y&#39;all, <br><br>I&#39;m excited to publicly publish =
a new protocol I&#39;ve been working on over the<br>past few months: Taro. =
Taro is a Taproot Asset Representation Overlay which<br>allows the issuance=
 of normal and also collectible assets on the main Bitcoin<br>chain. Taro u=
ses the Taproot script tree to commit extra asset structured meta<br>data b=
ased on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or<br>M=
S-SMT. An MS-SMT combined the properties of a merkle sum tree, with a spars=
e<br>merkle tree, enabling things like easily verifiable asset supply proof=
s and<br>also efficient proofs of non existence (eg: you prove to me you&#3=
9;re no longer<br>committing to the 1-of-1 holographic beefzard card during=
 our swap). Taro asset<br>transfers are then embedded in a virtual/overlay =
transaction graph which uses a<br>chain of asset witnesses to provably trac=
k the transfer of assets across<br>taproot outputs. Taro also has a scripti=
ng system, which allows for<br>programmatic unlocking/transfer of assets. I=
n the first version, the scripting<br>system is actually a recursive instan=
ce of the Bitcoin Script Taproot VM,<br>meaning anything that can be expres=
sed in the latest version of Script can be<br>expressed in the Taro scripti=
ng system. Future versions of the scripting system<br>can introduce new fun=
ctionality on the Taro layer, like covenants or other<br>updates.<br><br>Th=
e Taro design also supports integration with the Lightning Network (BOLTs) =
as<br>the scripting system can be used to emulate the existing HTLC structu=
re, which<br>allows for multi-hop transfers of Taro assets. Rather than mod=
ify the internal<br>network, the protocol proposes to instead only recogniz=
e &quot;assets at the edges&quot;,<br>which means that only the sender+rece=
iver actually need to know about and<br>validate the assets. This deploymen=
t route means that we don&#39;t need to build up<br>an entirely new network=
 and liquidity for each asset. Instead, all asset<br>transfers will utilize=
 the Bitcoin backbone of the Lightning Network, which<br>means that the int=
ernal routers just see Bitcoin transfers as normal, and don&#39;t<br>even k=
now about assets at the edges. As a result, increased demand for<br>transfe=
rs of these assets as the edges (say like a USD stablecoin), which in<br>wi=
ll turn generate increased demand of LN capacity, result in more transfers,=
 and<br>also more routing revenue for the Bitcoin backbone nodes.<br><br>Th=
e set of BIPs are a multi-part suite, with the following breakdown:<br>=C2=
=A0* The main Taro protocol: <a href=3D"https://github.com/Roasbeef/bips/bl=
ob/bip-taro/bip-taro.mediawiki">https://github.com/Roasbeef/bips/blob/bip-t=
aro/bip-taro.mediawiki</a><br>=C2=A0* The MS-SMT structure: <a href=3D"http=
s://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki">https=
://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki</a><br>=
=C2=A0* The Taro VM: <a href=3D"https://github.com/Roasbeef/bips/blob/bip-t=
aro/bip-taro-vm.mediawiki">https://github.com/Roasbeef/bips/blob/bip-taro/b=
ip-taro-vm.mediawiki</a><br>=C2=A0* The Taro address format: <a href=3D"htt=
ps://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki">https:=
//github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki</a><br>=C2=
=A0* The Taro Universe concept: <a href=3D"https://github.com/Roasbeef/bips=
/blob/bip-taro/bip-taro-universe.mediawiki">https://github.com/Roasbeef/bip=
s/blob/bip-taro/bip-taro-universe.mediawiki</a><br>=C2=A0* The Taro flat fi=
le proof format: =C2=A0<a href=3D"https://github.com/Roasbeef/bips/blob/bip=
-taro/bip-taro-proof-file.mediawiki">https://github.com/Roasbeef/bips/blob/=
bip-taro/bip-taro-proof-file.mediawiki</a><br><br>Rather than post them all=
 in line (as the text wouldn&#39;t fit in the allowed size<br>limit), all t=
he BIPs can be found above.<br><br>-- Laolu<br></div>

--00000000000003d9d405dbe9968b--