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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
Return-Path: <orlovsky@lnp-bp.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 28B50C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 22:18:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id E432182018
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 22:18:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E432182018
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=lnp-bp.org header.i=@lnp-bp.org header.a=rsa-sha256
header.s=protonmail2 header.b=lJCg1RfG
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Nt2uXyO3AsO6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 22:18:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 24D2A82004
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17])
by smtp1.osuosl.org (Postfix) with ESMTPS id 24D2A82004
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Apr 2023 22:18:07 +0000 (UTC)
Date: Wed, 19 Apr 2023 22:17:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lnp-bp.org;
s=protonmail2; t=1681942685; x=1682201885;
bh=KKKT8oLxz2u/M5NmKm6nZGNPM/JLQsXECEmLOVQLJvk=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=lJCg1RfGjt7EEOfHasfZMJ8F685bqS8YX01Ly2tXopybBj+bHlIZ06Nj5Il4Fk2f4
IntWFOz3twyXzjKY8wJwZcJTypKlJupdBC67L2MhwX9OnFE7XWks8Ur2fNvUTAgvi2
42TO0HevRqZZJoGeIjJcTHdEIt96dIfeSIDqShO6G+QRv9Ydod92mCqDWuCbVOsS5g
kQK9ghnBn3A6KlRb0AsgMG76jSeGuiGZSYtkSA+534WIkoIfjoP4K19ixiwp7shjeD
qS0G5VfKpTcgCtzVp1/qcAh7nAjhtEk050UpDMftTDolc2Evex64yPEALVRbqcJQ9A
Ip6drCE5D5CxA==
To: "David A. Harding" <dave@dtrt.org>
From: Dr Maxim Orlovsky <orlovsky@lnp-bp.org>
Message-ID: <laGWWZiHcM2wPyvD-EL62eW0mydFULvYnuhir99pRC_ZTB6ZIR6KObnlCWM7g35ExkMwFlmyj38UMWx37AFyfTOGDuKxhaSDXR3QEAk3xZ4=@lnp-bp.org>
In-Reply-To: <d34c6e5c4a776acfb455e549440a7c10@dtrt.org>
References: <JpC1PVaT1XunO5ZCcan4GkylS8cUadw8ueukJhEyfdFu2tzHa1CqcXT8vZDytu3ZEX9qPJ1pqG85NfqZ0cwGerHLXh3ZrUTXksxoPxuYyxA=@lnp-bp.org>
<3089493b2f202e30af42a485efec3fd1@dtrt.org>
<o80w3onSFX0O35gdZWrApKpor9gfV57gvgogoZGZDuC6KRc_DOsU0QRuEuOBkrRLYpFgOPxFUVnIjjSN6KDSgHXztIGXFREHvN5EPZ9e1oQ=@lnp-bp.org>
<d34c6e5c4a776acfb455e549440a7c10@dtrt.org>
Feedback-ID: 18134079:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 20 Apr 2023 00:44:56 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] RGB protocol announcement
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: Wed, 19 Apr 2023 22:18:12 -0000
Hi David,
> Ok, I think I understand you, but I'd like to try rephrasing what you
> wrote in a very brief format to see if you agree that it's correct and
> in the hopes that it might help other Bitcoin/LN developers understand.
In your description you mix together question of how BTC* can be issued
and how the contract settlement happens. However, they must be=20
distinguished, otherwise the contract trust model can't be anyhow better
than a fixed centralized BTC* design you add to the equation as an=20
assumption:
> What it doesn't provide is trustless contracting beyond the=20
> capabilities of Bitcoin script.
However:
1. Contract x*2=3D4 settlement is fully trustless.
2. BTC* contract settlement may vary.
One may argue that there is no way of getting BTC* in a trustless way,=20
but this is not true:
1. We may have a trustless BTC* in lightning channels (including
multiparty channels with many participants).
2. It also depends on how you define the value of the original BTC.
If BTC is a coin existing in bitcoin blockchain, than yes - you
can't have a fully trustless BTC* for on-chain operations. But if
you define BTC as a digital scarcity strictly inheriting existing
UTXO set from bitcoin blockchain, but which may exist elsewhere
than bitcoin blockchain, you may have a 100% trustless BTC*.
What can be a case for (2)? As I told in my first letter, with RGB
we do not need the existing heavy-duty bitcoin blockchain at all.
We still need a layer 1 settlement for our single-use-seals, but it may
have a very different design comparing to existing bitcoin blockchain.
At LNP/BP Standards Association we are working on such design for the
last 3 years, and have quite a lot of progress in this direction. The
design we have for the layer 1 needed for client-side-validation=20
(which Peter Todd calls "proof of publication medium") can be=20
represented as a single signature + pubkey per block, scaling up to
theoretically unlimited number of transactions. There are still some
problems we have to solve, but overall the direction seems realistic.
So, if/once we have a new blockchain, RGB (or its successor) can=20
operate on both bitcoin blockchain (let's call it timechain) and the=20
new blockchain (we call the new blockchain "sigchain" or "sealchain",=20
depending on the design model - we currently have 2 of them). Than, BTC
can be 100% trustlessly lifted from the timechain into RGB - and than
operate on top of the sigchain. In this model no pegout would be ever
needed, and the last point of trust gets removed.
> In short, I think this capability of RGB allows easily creating
> user-defined sidechains based on arbitrary scripts.
True, but RGB capabilities are even much larger than that. There is a=20
plenty of smart contracts which do not need BTC/BTC* at all and can=20
operate on RGB even today - but which were impossible on bitcoin=20
blockchain or lightning before RGB (at least without heavily polluting=20
block space):
1. Bearer securities - corporate shares, bonds, options, futures etc.=20
They will be 100% confidential and censorship-resistant + scalable
b/c of Lightning network. Yes, you still trust the issuer (like with
corporate shares), but the the secondary market is much improved.
2. Bearer ownership rights ("NFTs done in the right way"), again
private, scalable, not polluting blockchain. For instance, I would
like to have all books & songs as a bought to be present in this
format. This also opens options for creators to earn commissions not
just from an initial sale, but also from secondary market.
3. Digital collateral-based stable coins (in terms of their purchasing
power and not necessary linked to any fiat).
4. Digital identity, where RGB and single-use-seals make key revocation
a global event. Without this it is impossible to prove that a given
key was or was not revoked at certain date.
5. Decentralized naming systems - like ENS, but much better because
no ethereum is required :)
6. Provable historical event logs: opentimestamps doesn't allow
proving that there is no alternative commitments. With RGB it is=20
possible to build event logs which has 100% trustless provable
properties that no alternative history of the events does exist.
For instance, if a doctor gives a prediction that a baby will be
a boy and not a girl, it is impossible to witness the case with
OpenTimeStamp (the doctor can make 2 OTSes for both outcomes),
while with RGB it can be proven that no alternative commitment was
created.
7. Liquidity pools, DEXes, AMM and other fancy stuff on Lightning,
which we call "BiFi" (Bitcoin finance). One may listen to the talk
on the last Bitcoin Amsterdam conference where I have presented
that concept [1]. It requires more than just RGB - also some
improvements to the Lightning network and protocols like Storm
as a decentralized (tokenless!) data layer - but all of that is
WIP at LNP/BP Standards Association with many parts already being
released in a test versions (another reason why LNP Node is
important - a topic we were discussing two e-mails ago).
Thus we say that RGB allows everything what can be done with existing
"blockchain smart contracts" - but in much more scalable,=20
privacy-preserving way and with bitcoin, not requiring new/other=20
tokens. Arguably, this is the largest thing that happened to bitcoin=20
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,=20
especially when gossip traffic and liquidity limitations are taken
into account).
The time will show where all these assumptions about the potential of
sigchain and #BiFi are correct. Meanwhile, we at LNP/BP Standards
Association continue our work on advancing bitcoin protocol and
lightning network protocols - without whining about any soft- or hard-
forks :). Of course, we, as a non-profit, need support - so all bitcoin
hodlers are welcome to join the very few organizations and individuals
already supporting our efforts [2], making all this future possible=20
(you can contact us via "ukolova [at] lnp-bp.org").
At the end, I'd like t, thank you for the detailed analysis and great
write-up on RGB in the latest Bitcoin Optech Newsletter. It explains
RGB in more simple words than I was was able to!
Kind regards,
Maxim Orlovsky
LNP/BP Standards Association
GitHub: https://github.com/LNP-BP
Twitter: @lnp_bp
[1]: https://www.youtube.com/watch?v=3DDtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/
|
