1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8EA42C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Apr 2022 20:23:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 6DBB060D72
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Apr 2022 20:23:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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,
RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id PECqSNNjFIaf
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Apr 2022 20:23:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo95.poczta.onet.pl (smtpo95.poczta.onet.pl
[213.180.149.148])
by smtp3.osuosl.org (Postfix) with ESMTPS id C495660B96
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Apr 2022 20:23:13 +0000 (UTC)
Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4KXzbs6FhPzlgMqS;
Tue, 5 Apr 2022 22:23:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1649190186; bh=pvJK5IFy+1JIVlls/Y+ri9wVrxpufF4m5lB+u+eAEFo=;
h=From:To:Date:Subject:From;
b=GE+oO6/YcGsvIxaoBJWRjzFaRdbPEKGRHzyzU2L/c4lXDSQ/LP7N36hwuH3MxDdvd
ByRPasKPjMTDztk2fkMQMWwCkfubZcaGT2ym73cjiKhZMdkMBcP50/NU9AQLOdXwK/
oXtDpKBBNMD446FuoKCEPlF5rZxBhZrTWc/EahaY=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.224.13] by pmq4v.m5r2.onet via HTTP id ;
Tue, 05 Apr 2022 22:23:05 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
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>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.224.13;PL;2
X-Mailman-Approved-At: Tue, 05 Apr 2022 22:32:14 +0000
Subject: Re: [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 20:23:16 -0000
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
|
