* [bitcoin-dev] RGB protocol announcement
@ 2023-04-10 22:09 Dr Maxim Orlovsky
2023-04-16 5:34 ` David A. Harding
0 siblings, 1 reply; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-10 22:09 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
TL;DR
-----
LNP/BP Standards Association <https://www.lnp-bp.org>, supported by Fulgur
Ventures, Bitfinex, Hojo Foundation, Pandora Prime, and DIBA, is happy to
announce the release of RGB v0.10 - the next significant milestone in the RGB
protocol <https://rgb.tech> which brings full support of smart contracts to
Bitcoin and Lightning. This is the result of a great cross-industry long-term
collaboration between these bitcoin companies and more than four years of
extensive development work.
RGB v0.10 can be downloaded and installed as described on <https://rgb.tech>
website, which also contains a number of user and developer guidelines.
RGB source code can be found on <https://github.com/RGB-WG>
Background of RGB
-----------------
Some of you might remember the announcement of RGB protocol idea back in
2018 [1]: it was an idea of “colored coins” over Lightning by Giacomo
Zucco, based on new concepts developed by Peter Todd - client-side-validation
and single-use-seals.
In 2019 me (Maxim Orlovsky) and Giacomo Zucco formed the LNP/BP Standard
Association, aiming to bring RGB from the concept to production. The initiative
was supported by Bitfinex and Fulgur Ventures. My goal with RGB was not just to
enable assets on Lightning, but that of a much larger scope: to build a
programmability layer for Bitcoin and Lightning, which may unlock other cases
than just tokens - DAOs, decentralized identities and other things that
bitcoin itself was lacking. This took much longer than was expected, and both
myself and the LNP/BP Standards Association had gone through very turbulent
times on this road, relying on self-financing for more than a year...
Nevertheless, in 2021 we were able to present both RGB powered with a
Turing-complete virtual machine (AluVM) [2] and RGB had became operational on
Lightning Network [3] using the LNP Node - a complete rust re-implementation of
the Lightning protocol made by me at the Association [4]. Those who are
interested in the history of RGB development and our past releases may refer
to it graphical representation [5] - or navigate through years of videos and
demos on our YouTube channel <https://www.youtube.com/@LNPBP/videos>.
Despite 4 years of active development, weekly community calls, talks on
all mainstream bitcoin-only evens and conferences, the awareness about RGB
in the bitcoin community is still very small - and some bitcoin media put
as a requirement for us to submit information about RGB to the bitcoin-dev mail
list, so that they could see the new technology that has been developed -
so here we are.
RGB v0.10
---------
Today we’d like to announce the next main milestone: **release of RGB v0.10**,
which includes consensus layer, standard library (used by wallets/exchanges
for integration) and a command-line tool.
v0.10 release is a major milestone which brings RGB further to being a
production-ready system. It introduces the last consensus-breaking changes,
aiming at keeping future RGB versions fully backward-compatible. It also unlocks
the last features that were required for implementing fully-functional smart
contracts which may be arbitrary customized by contract developers.
This release brings the support of the following features to RGB:
- ### Global state in RGB contracts
Now each RGB contract has a global state accessible by a virtual machine
and clients (wallets etc).
- ### Contract interfaces
Interfaces, introduced in this version, represent a standard way of
communicating a diverse range of smart contracts through well-defined APIs.
Interfaces can be compared to contract ABIs and ERCs in Ethereum world,
however, unlike in Ethereum, they require neither obligatory standardization
(as ERCs) nor separate distribution, being always packed together with
contracts. By using interfaces, wallets and other software can provide a
semantic-aware UI for the users for working with the contracts - and contract
developers may add more interfaces to their existing contracts over time
without the need to update the immutable contract itself.
- ### Strict type system
Strict types is a new functional data type system with provable
properties used for the RGB contract state representation and introspection.
It allows compile-time guarantees on the size of any data, simplifying RGB
operations on low-end and limited-memory devices like hardware wallets.
The whole RGB consensus layer is now compiled into strict types, which
allows formal proofs of the binary compatibility between releases (the
feature which might have been very useful for bitcoin consensus if it existed
back in the days of Satoshi). You can learn more about strict types on
<https://www.strict-types.org>
- ### Contracts in Rust
Writing and compiling an RGB smart contracts in Rust. Thanks to the strict
types, it is also possible to compile rust data types right into RGB
contracts.
- ### State introspection
Contracts can introspect their own state in the validation code used by the
virtual machine, which unlocks the way for writing complex forms of contracts
working with bitcoin transactions, DLCs and other complex data.
- ### URL-based invoice format
Previously RGB was using Bech32m-encoded invoices, which were very long,
not human-readable and couldn't be automatically opened with most of the
software. The new format is much shorter, easier to verify by the user and
can be opened automatically as a link with a preconfigured software.
- ### WASM support
RGB standard library can run without I/O and file system access,
i.e. can operate inside a web page or a browser plugin.
- ### Tapret descriptors and custom derivation
RGB uses taproot-based OP_RETURN commitments (in short - tapret), which
require support on the descriptor level such that wallets could see the
transactions with tweaked outputs as those belonging to the wallet descriptor.
New version also introduces custom derivation indexes that prevent non-RGB
wallets from accidentally spending outputs with RGB assets (and thus -
destroying assets).
- ### Simplified dependencies
RGB consensus layer is being shipped with fewer dependencies, improving the
stability of API. We have abandoned the dependency on custom bulletproofs
implementation from Grin projects. We also do not use rust-bitcoin and
rust-miniscript due to their overall API instability and recently discovered
bugs; since RGB uses a very small subset of bitcoin functionality it is now
implemented as a part of the library with no assumptions about bitcoin
consensus layer (like those which halted rust-bitcoin powered software when
Burak's hack had happened last year).
- ### Simplified integration
Many operations that previously required multiple API calls, as well as
cross-language encoding of complex data structures now work with a
single API call. RGB contract state is represented as a JSON object and
can be serialized across different languages without a hassle.
- ### Simplified UX
Previously, to use RGB, a wallet or a user had to run the RGB Node, interface
it through RPC (or cli tool) - and use a number of other libs and command-line
tools to perform most of the operations on PSBTs etc. With the new release
this complex stack was replaced by a single library API and a command-line
tool `rgb`, which operate like a swiss knife for RGB user (and it can be
compared to the way `git` works). RGB Node still can be run by users on their
home servers, but is not obligatory for using RGB anymore.
### Migration notes
There is no migration from contracts issued on RGB v0.9 to the future versions.
All assets have to be re-issued; asset holders can contact asset issuers to
provide them with a newly re-issued contracts and assets matching the assets
from v0.9.
RGB v0.10 can be downloaded and installed as described on [https://rgb.tech]
(https://rgb.tech) website, which also contains a number of user and
developer guidelines. RGB source code can be found on https://github.com/RGB-WG
Roadmap after v0.10
-------------------
With this release the future development of the core RGB technology (at in its
consensus layer) becomes gradually ossified, as the cases of
client-side-validated systems upgrades are more complex to coordinate than
those of blockchain layer 1. Also, the normal understanding of soft-forks and
hard-forks do not apply to upgrades in layer 2 and 3. So we found a way
for backwards-compatible upgrades, which we call “fast-forwards”, where users
keep their assets issued under the older versions that can always operate and be
accepted by the users of any other future version. However, the users of a newer
version will be restricted in transferring their assets only to the users of the
same or more recent version (but they can always ask recipients to upgrade their
software). We have a number of features planned for the future fast-forwards:
- full support of bitcoin layer 1 and channel state introspection;
- inter-contract interaction;
- bulletproofs++ support;
- zero-knowledge-based optimizations of the client-side-validated history.
We're also working on the design of a layer 1 which will be perfect for the
client-side-validated applications (“how to design a blockchain today if we
knew about client-side-validation/single-use-seals”). This should be very
compact (order of one signature per block) ultra-scalable (theoretically
unlimited no of tx in a block) chain which can run systems like RGB - with
Bitcoin UTXO set migrated into RGB operating on both bitcoin blockchain and
this new chain (we code-name it “sigchain”). However, these are quite early
developments with a number of unsolved tradeoffs and challenges; if there is
an interest on this topic here we can start a different discussion thread
on the matter.
Software and integrations
-------------------------
Companies, which are a part of the LNP/BP Standards Association, as well
as other independent vendors are already working on upgrading their software
to v0.10. This includes (but not limited to):
- MyCitadel wallet (iOS, Desktop)
- Iris wallet (Android) from RGB team inside Bitfinex
- BitMask (Web browser plugin) from DIBA
- LNP Node with RGB support - lightning node from the LNP/BP Standards Association
- RGBEx.io - website listing RGB assets and contracts,
using pseudonymous credentials (public key + signatures)
- RGB Tools library - SDK based on BitcoinDevKit for RGB wallet integration
- LightningDevKit with RGB support - again by RGB team in Bitfinex
- Core Lightning RGB plugin
LNP/BP Standards Association will focus its further development activity
around these three areas:
- Completing RGB documentation, specification and helping public audits of the
technology. Right now we have a nearly-complete RGB whitepaper [6] a codified
standards [7]
- Lightning network support for complex RGB smart contracts - the thing we name
#BiFi (Bitcoin finance) [8]. It includes further development of Storm -
a decentralized data storage & messaging network on top of Lightning, that we
presented last year.
- RGB toolchain, which includes a new high-level functional smart contracting
language called Contractum (<https://www.contractum.org>) and other tools
which will simplify the life of RGB devs.
Sources of information
----------------------
We have already witnessed some actors distributing misinformation about
non-existing products released with/on RGB even before the official releases of
some RGB components happened. Thus, we advise all media people to always check
the official sources before publishing information about the RGB protocol.
All releases and major things are being announced on:
* Official website of the protocol <https://rgb.tech>,
community <https://rgbfaq.com> and LNP/BP Standards Association
<https://lnp-bp.org>.
* Twitter of the Association: <https://twitter.com/lnp_bp>
* Community telegram channel: <https://t.me/rgbtelegram>
Other websites are not in control of the RGB protocol developers and are not
open-source and should not be considered to be trusted sources of information.
-------------------------
Maxim Orlovsky
Mail: orlovsky [at] lnp-bp.org
Github: https://github.com/dr-orlovsky
Twitter: https://twitter.com/dr_orlovsky
PGP: EAE7 30CE C0C6 6376 3F02 8A58 6009 4BAF 18A2 6EC9
[1]: https://www.youtube.com/watch?v=xHWxtmgQP94
[2]: https://www.youtube.com/watch?v=Mma0oyiVbSE
[3]: https://www.youtube.com/watch?v=6Svmh0OQVf4
[4]: https://github.com/LNP-WG/lnp-node
[5]: https://twitter.com/dr_orlovsky/status/1640833926456307714/photo/1
[6]: https://blackpaper.rgb.tech
[7]: https://standards.lnp-bp.org
[8]: https://www.youtube.com/watch?v=DtkTE6m0zio_
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-10 22:09 [bitcoin-dev] RGB protocol announcement Dr Maxim Orlovsky
@ 2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: David A. Harding @ 2023-04-16 5:34 UTC (permalink / raw)
To: Dr Maxim Orlovsky, Bitcoin Protocol Discussion
Hi Dr Orlovsky,
Thank you for writing about your interesting project. Some replies
inline below:
On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
> RGB v0.10 can be downloaded and installed as described on
> <https://rgb.tech>
> website, which also contains a number of user and developer guidelines.
> RGB source code can be found on <https://github.com/RGB-WG>
FYI: the RGB-WG organization page links to a repository whose latest
release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
https://github.com/RGB-WG/rgb-node/
> My goal with RGB was not just to enable assets on Lightning, but that
> of a much larger scope: to build a programmability layer for Bitcoin
> and Lightning, which may unlock other cases than just tokens - DAOs,
> decentralized identities and other things that bitcoin itself was
> lacking.
Is there any documentation or discussion archives that address the
problem of non-publishable conditional statements seemingly being
insecure in
multiparty protocols, as previously described on this list[1] by Ruben
Somsen? To give my own example of the problem:
- Bob doesn't believe that there's a number which can be multiplied by 2
to produce 4. He's willing to pay a bounty for proof that he's wrong
but Bitcoin does not currently provide a multiplication opcode, so he
can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
- Bob hears that RGB has turing-complete scripting, so he buys some
random tokens that have an RGB contract which allows him to encumber
them by any AlumVM script. He then creates a Bitcoin transaction
signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
solution to (x * 2 == 4) to spend his RGB-based tokens. He publishes
a PSBT for the transaction along with the RGB data needed to claim the
tokens.
- Anyone on the network can now claim the BTC without knowing the
solution, destroying the RGB-based tokens.
- If, instead, Bob hears that Mallory knows the solution, he could sign
a
PSBT with the default SH_ALL to her, but then Mallory could take the
BTC without solving the problem, again destroying the RGB-based
tokens.
- Or, in another case, Bob hears that Alice knows the solution, but he
doesn't want to risk his tokens being destroyed, so he refuses to sign
a transaction paying Alice until she provides him the answer. When
Alice does provide him the answer, and he realizes it's so simple, he
changes his mind about paying her and doesn't sign his transaction to
her. She has no recourse.
It seems to me, based on my understanding of Somsen's original insight,
that client-side validation by itself cannot enforce conditions in a
trustless multiparty setting.
I think that implies that it's only possible to enforce conditions in a
consensus system (or in a trust-dependent system), which would have
significant implications for the future direction of your work, as you
wrote in your email:
> We're also working on the design of a layer 1 which will be perfect for
> the
> client-side-validated applications (“how to design a blockchain today
> if we
> knew about client-side-validation/single-use-seals”). This should be
> very
> compact (order of one signature per block) ultra-scalable
> (theoretically
> unlimited no of tx in a block) chain which can run systems like RGB -
> with
> Bitcoin UTXO set migrated into RGB [...]
* * *
Looking at other parts of your email:
> Nevertheless, in 2021 we were able to present both RGB powered with a
> Turing-complete virtual machine (AluVM) [2] and RGB had became
> operational on
> Lightning Network [3] using the LNP Node - a complete rust
> re-implementation of
> the Lightning protocol made by me at the Association [4].
Could you clarify the status of these implementations? While trying to
learn about RGB, I noticed that you don't have much completed
documentation. Previous reviewers also mentioned this and I saw that
you suggested them to read the code or view your videos.
When reading your code for your LN implementation (LNP), I noticed it
seemed to be missing a lot of things present in other LN implementations
I regularly review. For example, I can't find where it supports
creating or parsing onions, which seems to be a fundamental requirement
for using LN. In trying to figure out how it works, I also noticed that
I couldn't find either unit tests or integration tests---indeed several
of your applications seem to almost entirely lack the string "test".
For example, here are LNP-node and RGB-node compared to the four LN
implementations I regularly monitor:
/tmp/rgb-node$ git grep -i '\<test\>' | wc -l
7
/tmp/lnp-node$ git grep -i '\<test\>' | wc -l
4
~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
2008
~/repos/cln$ git grep -i '\<test\>' | wc -l
1459
~/repos/lnd$ git grep -i '\<test\>' | wc -l
3547
~/repos/eclair$ git grep -i '\<test\>' | wc -l
2576
I realize those are all projects by larger teams than that which works
on RGB, but a difference of three orders of magnitude is very surprising
to me. Do you have out-of-tree testing or am I missing something else?
I did my best to earnestly search both your repository and your GitHub
issues and PRs. All I found was that a small amount of previous unit
testing was removed, and that several issues mentioning the need for
testing were closed without referencing a resolution.
As your replies to previous reviewers also mentioned that they should
view your Youtube videos, I also tried that. I focused on the ones
discussing LNP, as LN is something I know fairly well, and I admit that
I skimmed them quite fast, but I couldn't find any demos where you
progressed beyond using LNP to open a channel with another node. E.g.,
they seemed to stop at the same point as this demo:
https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
> Despite 4 years of active development, weekly community calls, talks on
> all mainstream bitcoin-only evens and conferences, the awareness about
> RGB
> in the bitcoin community is still very small
My understanding of the basic goal of RGB from years ago was that it
would allow ordinary users to define new assets on Bitcoin in a way that
would allow those assets to be transferred over LN. As far as I can
tell, it doesn't do that yet, not even in a way that's accessible to a
power user such as myself. Even for that original goal, there are
several problems outstanding---problems which will likely require
significant research and experimentation to overcome, e.g.[2].
Instead of tackling those problems and building upon existing wallet and
LN libraries, I see an ambitious effort at reimplementation and massive
scope creep. The payoff for that effort could be a huge change that
affects how we use Bitcoin and LN for decades to come. But it also
seems possible that the ambition and scope creep may be preventing the
project from currently serving many of the people who were most excited
about it in the first place. Awareness may be limited because the
near-term benefits for most people who invest time in learning about RGB
also seems limited.
Thanks again for writing about your research for this mailing list,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003540.html
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003549.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-16 5:34 ` David A. Harding
@ 2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky
2 siblings, 0 replies; 7+ messages in thread
From: Federico Tenga @ 2023-04-16 7:15 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8479 bytes --]
To add some context to the conversation, I would like to point out that
another RGB lightning implementation exists based on LDK, you may want to
check it out to have a better picture of how RGB works on LN:
https://github.com/RGB-Tools/rgb-lightning-sample
On Sun, 16 Apr 2023 at 07:35, David A. Harding via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi Dr Orlovsky,
>
> Thank you for writing about your interesting project. Some replies
> inline below:
>
> On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
> > RGB v0.10 can be downloaded and installed as described on
> > <https://rgb.tech>
> > website, which also contains a number of user and developer guidelines.
> > RGB source code can be found on <https://github.com/RGB-WG>
>
> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/
>
> > My goal with RGB was not just to enable assets on Lightning, but that
> > of a much larger scope: to build a programmability layer for Bitcoin
> > and Lightning, which may unlock other cases than just tokens - DAOs,
> > decentralized identities and other things that bitcoin itself was
> > lacking.
>
> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in
> multiparty protocols, as previously described on this list[1] by Ruben
> Somsen? To give my own example of the problem:
>
> - Bob doesn't believe that there's a number which can be multiplied by 2
> to produce 4. He's willing to pay a bounty for proof that he's wrong
> but Bitcoin does not currently provide a multiplication opcode, so he
> can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
>
> - Bob hears that RGB has turing-complete scripting, so he buys some
> random tokens that have an RGB contract which allows him to encumber
> them by any AlumVM script. He then creates a Bitcoin transaction
> signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
> solution to (x * 2 == 4) to spend his RGB-based tokens. He publishes
> a PSBT for the transaction along with the RGB data needed to claim the
> tokens.
>
> - Anyone on the network can now claim the BTC without knowing the
> solution, destroying the RGB-based tokens.
>
> - If, instead, Bob hears that Mallory knows the solution, he could sign
> a
> PSBT with the default SH_ALL to her, but then Mallory could take the
> BTC without solving the problem, again destroying the RGB-based
> tokens.
>
> - Or, in another case, Bob hears that Alice knows the solution, but he
> doesn't want to risk his tokens being destroyed, so he refuses to sign
> a transaction paying Alice until she provides him the answer. When
> Alice does provide him the answer, and he realizes it's so simple, he
> changes his mind about paying her and doesn't sign his transaction to
> her. She has no recourse.
>
> It seems to me, based on my understanding of Somsen's original insight,
> that client-side validation by itself cannot enforce conditions in a
> trustless multiparty setting.
>
> I think that implies that it's only possible to enforce conditions in a
> consensus system (or in a trust-dependent system), which would have
> significant implications for the future direction of your work, as you
> wrote in your email:
>
> > We're also working on the design of a layer 1 which will be perfect for
> > the
> > client-side-validated applications (“how to design a blockchain today
> > if we
> > knew about client-side-validation/single-use-seals”). This should be
> > very
> > compact (order of one signature per block) ultra-scalable
> > (theoretically
> > unlimited no of tx in a block) chain which can run systems like RGB -
> > with
> > Bitcoin UTXO set migrated into RGB [...]
>
> * * *
>
> Looking at other parts of your email:
>
> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations? While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation. Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.
>
> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review. For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN. In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\<test\>' | wc -l
> 7
> /tmp/lnp-node$ git grep -i '\<test\>' | wc -l
> 4
>
> ~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
> 2008
> ~/repos/cln$ git grep -i '\<test\>' | wc -l
> 1459
> ~/repos/lnd$ git grep -i '\<test\>' | wc -l
> 3547
> ~/repos/eclair$ git grep -i '\<test\>' | wc -l
> 2576
>
> I realize those are all projects by larger teams than that which works
> on RGB, but a difference of three orders of magnitude is very surprising
> to me. Do you have out-of-tree testing or am I missing something else?
> I did my best to earnestly search both your repository and your GitHub
> issues and PRs. All I found was that a small amount of previous unit
> testing was removed, and that several issues mentioning the need for
> testing were closed without referencing a resolution.
>
> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that. I focused on the ones
> discussing LNP, as LN is something I know fairly well, and I admit that
> I skimmed them quite fast, but I couldn't find any demos where you
> progressed beyond using LNP to open a channel with another node. E.g.,
> they seemed to stop at the same point as this demo:
>
> https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
>
> > Despite 4 years of active development, weekly community calls, talks on
> > all mainstream bitcoin-only evens and conferences, the awareness about
> > RGB
> > in the bitcoin community is still very small
>
> My understanding of the basic goal of RGB from years ago was that it
> would allow ordinary users to define new assets on Bitcoin in a way that
> would allow those assets to be transferred over LN. As far as I can
> tell, it doesn't do that yet, not even in a way that's accessible to a
> power user such as myself. Even for that original goal, there are
> several problems outstanding---problems which will likely require
> significant research and experimentation to overcome, e.g.[2].
>
> Instead of tackling those problems and building upon existing wallet and
> LN libraries, I see an ambitious effort at reimplementation and massive
> scope creep. The payoff for that effort could be a huge change that
> affects how we use Bitcoin and LN for decades to come. But it also
> seems possible that the ambition and scope creep may be preventing the
> project from currently serving many of the people who were most excited
> about it in the first place. Awareness may be limited because the
> near-term benefits for most people who invest time in learning about RGB
> also seems limited.
>
> Thanks again for writing about your research for this mailing list,
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003540.html
> [2]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003549.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 10354 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
@ 2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky
2 siblings, 0 replies; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-18 0:47 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi David,
Thank you for taking time on doing analysis and writing comments.
I will address all small questions in this reply -- with a follow-up
e-mail dedicated to the technical question from your letter
regarding the problem of "on-publishable conditional statements seemingly
being insecure in multiparty protocols", which requires longer write-up.
> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/
Thank you for spotting; we hadn't updated the readme. Now its fixed.
> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations?
The status of LNP implementation is "experimental": it is an instrument
for testing new protocols in the scope of the Lightning network, and
its main feature is in having lightweight and modular architecture.
LNP implementation is not anymore required for using RGB on LN - as
Federico already mentioned in his reply, Bitfinex team was able to
independently integrate RGB with existing LDK codebase [1] (I even
didn't know about that before they announced), and there is a WIP on
integrating RGB through CLN extensions. So the question of LNP node
readiness/completeness is unrelated to the question of RGB readiness,
features or technical properties; in my previous e-mail I just had
pointed out that at some (past) point in time we had to work on LN
re-implementation due to some restrictions we had back those days --
like with pay-to-contract commitments which were impossible to
implement in the existing nodes due to architecture limitations --
but with the change to taproot-based commitments in late 2021-
early 2022 this is not true anymore.
> While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation. Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.
A lot of documentation was written and is being written. For instance,
if you look at the foundational crates we have in RGB, they are
well documented, containing more docs than the code itself, like in
<https://github.com/LNP-BP/client_side_validation/blob/master/single_use_seals/src/lib.rs>
Also, we have a number of websites tracking the RGB docs, listed in
<https://rgb.tech/docs/> and <https://rgb.tech/learn/> - literally
dozens of them. So your information is outdated.
Of course, much more need to be written - but again, for a small team
of community & self-fundend non-profit with the budget comparable to
a coffee shop. I think we are doing all what we can. If community
needs more docs -- it is welcome to provide more funding or hands in
writing them.
> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review. For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN.
It is there, literally for years, where it should be - in P2P protocol,
BOLT4, as directory and file names suggest:
<https://github.com/LNP-WG/lnp-core/blob/master/lnp2p/src/bolt/bolt4.rs>
It is based on our other library which provides encryption:
<https://docs.rs/internet2/0.9.0/internet2/presentation/sphinx/index.html>
> In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\<test\>' | wc -l
> 7
RGB Node is not a part of the current RGB release -- starting from
v0.10 RGB do not require a background service. The node is still useful
in server-side environments - but 100% of mobile and most of desktop
users and wallet devs would never need to touch it; thus the update
of the node to v0.10 will come later. Anyway, there is no reason of
doing its extensive test coverage since it its role to be a wrapper
around RGB libraries (existing in other repositories) which contain
100% of RGB consensus and applied business logic. Node just manages
threads and file I/O - not the stuff which is test-covered first of
all (and even for that task it uses others of our libraries with a
like io-react, used in other high-load projects. (BTW pls pay
attention to how such libs are documented:
<https://docs.rs/io-reactor/0.1.2/reactor/>).
The real RGB code is here, as it is clearly stated in the Github:
* consensus-level
- <github.com/RGB-WG/rgb-core>
- <github.com/BP-WG/bp-core>
- <github.com/LNP-BP/client_side_validation>
* integration libraries - <github.com/RGB-WG/rgb-wallet>
With the update to v0.10 a lot of code was changed, so most of tests
got outdated and were thrown out. Yes, we need more time and
effort to re-do them -- but even taking that into the account,
the core of RGB is covered to much greater extent than the estimations
you have provided:
* client-side-validation library - 80%:
<https://app.codecov.io/gh/LNP-BP/client_side_validation>
* RGB Core - ~25% (due to significant re-write in v0.10)
<https://app.codecov.io/gh/RGB-WG/rgb-core>
Finally, the most of code coverage happens due to the used
strict types system [4], which does compilation-type verification
of all data serialization, deserialization and semantic type system.
I.e. with its taken into account, the actual code coverage exceeds
2/3 (>60%). I provide more explanations at the end of the letter.
> /tmp/lnp-node$ git grep -i '\<test\>' | wc -l
> 4
>
> ~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
> 2008
> ~/repos/cln$ git grep -i '\<test\>' | wc -l
> 1459
> ~/repos/lnd$ git grep -i '\<test\>' | wc -l
> 3547
> ~/repos/eclair$ git grep -i '\<test\>' | wc -l
> 2576
Well, that's a strange way to estimate the code coverage by counting
lines with the word "test". I usually use code coverage reports, like
those coming from codecov.com -- since neither count of unit tests nor
code lines in them are a valid metric to see how the code is
test-covered.
Unlike all those implementations, the node repository doesn't contain
any lightning network business logic or protocols - it is just a "shell"
providing I/O, networking and thread management, not requiring much
testing. Instead, one should look into the actual LNP codebase
implementing BOLT standards, which is in
<https://github.com/LNP-BP/lnp-core>. And as one might see from test
coverage reports [2] it has 40% of all code covered in tests - which
is not huge, yes, but (see next reply)...
> I realize those are all projects by larger teams than that which works
> on RGB, but a difference of three orders of magnitude is very surprising
> to me. Do you have out-of-tree testing or am I missing something else?
... as I pointed above, there is no "three orders of magnitude" difference
if the comparison is done correctly. Of course mainstream implementation
developed for more than 5 years, with millions invested by large companies/
non-profits and full teams of devs will have more test coverage than
an implementation created at my own personal expense - and I do not
understand what is surprising here :) I wrote about this implementation
to attract more interest from the community devs who may be interested
in joining to work/use an independent lightning re-implementation with
more open architecture allowing much larger protocol-level customizations
than any other mainstream implementation out there.
> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that.
I had never replied to previous _reviewers_ like that. For instance, the
protocol was reviewed by Peter Todd and Federico Tenga, as well as by
other devs from the community, and I am sure they can confirm that the
communications were complete and I was providing all the required answers
and comments. If you are talking about Ruben Somsen, he was never
introduced to me as a reviewer, nor wrote to me anything other than
several sarcastic tweets -- and I rather see him as an internet troll,
who, notwithstanding verbal communications and explanations I
had provided him over phone call, continues to spread miss-information
positioning himself as "RGB expert" -- while still demonstrating absence
of desire of reading any recent updates we had even when provided links.
> I focused on the ones
> discussing LNP, as LN is something I know fairly well,
But this discussion is an offtopic to RGB and this letter. I am fine to
have it, but let's move it to a separate thread.
> I skimmed them quite fast, but I couldn't find any demos where you
> progressed beyond using LNP to open a channel with another node. E.g.,
> they seemed to stop at the same point as this demo:
> https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
The current LNP Node version is v0.9, so v0.4-alpha is extremely outdated,
as well a doc there. For sure the doc needs an update. These are more
recent demos of node operations, with a remote CLN node as of end of 2021:
* https://youtu.be/DoNfKLLjzsY
* https://youtu.be/L6JlIQXbl6Y
> My understanding of the basic goal of RGB from years ago was that it
> would allow ordinary users to define new assets on Bitcoin in a way that
> would allow those assets to be transferred over LN. As far as I can
> tell, it doesn't do that yet, not even in a way that's accessible to a
> power user such as myself.
I do not know how to compare the power of users, but, for instance it
was successfully demonstrated by an independent Bitfinex team using BDK
and LDK last month on the stage of Lightning Tuscany Summit. Of course
there yet no fancy UI all around, but absence of UI says nothing about
technology or its readiness. In fact, several teams are working on the
first UI apps using RGB, so this thing will change - and it is not a
task for a non-profit protocol-level research organization, but rather
for commercial ventures.
> Even for that original goal, there are
> several problems outstanding---problems which will likely require
> significant research and experimentation to overcome, e.g.[2].
> Instead of tackling those problems and building upon existing wallet and
> LN libraries, I see an ambitious effort at reimplementation and massive
> scope creep.
Sorry for not meeting your expectations about how I should use my time,
funds and funds of those who support such developments :)
The real part of the story is that 80% of the time we were working
on solving the original scope you pointed out. It just appeared that
there were much more hidden stones (than was expected back in 2018)
in doing the idea of "assets over Lightning":
* the original single-use-seals didn't worked for the world of multiple
assets which may co-exists, which required development of a set of
quite complex protocols (still being probably most complex part
of RGB);
* the original pay-to-contract commitment scheme did work badly on
practice, being poorly inter-operable with existing lightning
implementations (which took a year of work on LNP node in total,
as I mentioned above) and leading to hard problems in wallet
integration and compatibility with all existing frameworks. We were
solving that problem until Taproot had arrived - and then we switched
to Taproot-based commitment scheme. It took another half of year
to update the whole code base - but the reward was compatibility
with BDK, LDK and other existing tools in the ecosystem, so your
comment on "Instead of tackling those problems and building upon
existing wallet and LN libraries" is not valid;
* as a part of the above, I had to significantly contribute to
taproot implementation and maintenance of rust-bitcoin project,
being the most active project contributor during the course of
2019-2022 [3] (="building upon existing wallet libraries);
* a lot of time was spent on privacy-related improvements, since none
of the original authors nor sponsors had seen any value about putting
"colored coins on lightning" without worriyng about the privacy;
and only after that comes some "fancy stuff", like doing a dedicated
virtual machine and rich data type system -- which primary features
were not "Turing completeness" but ability of formal verification and
compiler-time safety guarantees. For instance, the developed type
system [4] allows not just to "compile" any rust data type into a
smart contract, but also to prove that all data types used in
consensus code do not mutate between releases. If bitcoin had that
type system, there would be no "unnoticed" hardforks or risks of them
in a future -- and I think not implementing such system in doing a
new consensus protocol would be a poor decision. And the last, but
not least, I do not want to be in such situation
<https://twitter.com/fiatjaf/status/1647976362374844416?s=61&t=H4U6Q30N4eanvS4GjyAt4g>
preferring to spend a year more on a proper design instead of
"shipping earlier". What is acceptable for networking protocols
can't be acceptable for consensus-level protocols, which, unlike
even blockchain consensus can't have softforks.
----
Overall, I am quite negatively impressed with the amount of
misinterpretations and estimates which are simply wrong - and I know
that they are being floated around working like fake news.
Unfortunately writing answers to such claims takes a lot of time -
and takes it from doing other stuff like writing docs, tests or
integrations. I understand that this letter will be read by many,
thus I did address some of most common misconceptions. I am doing
that on bitcoin-dev mail list, but not elsewhere, since if I were
doing that on Twitter I would never have time for anything else.
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021558.html
[2]: https://app.codecov.io/gh/LNP-WG/lnp-core
[3]: https://github.com/rust-bitcoin/rust-bitcoin/graphs/contributors?from=2019-01-11&to=2022-04-11&type=c
[4]: https://www.strict-types.org
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
@ 2023-04-18 23:16 ` Dr Maxim Orlovsky
2023-04-19 19:37 ` David A. Harding
2 siblings, 1 reply; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-18 23:16 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi Harding,
This is the continuation from my previous e-mail [1] addressing the
largest and last unanswered question from your reply:
> To give my own example of the problem <… description follows …>
I am not entirely understand your argument or question, even though
I have spent a lot of time trying to crack it. For me it seems that
this is due to different paradigms we are thinking in. Client-side-
validation and work on RGB had required me to dramatically change
the way I see distributed systems, bitcoin and other “blockchains”
and multi-party contracts, thus this may have caused inability to
speak in the same terms. For me, the setup you are describing
doesn’t make sense at all: there is no reason of doing things with
RGB that way. I.e, you are suggesting invalid setup - and then
prove that it is not working :).
I will try first to explain why I think the reasoning you are
putting into the argument is invalid in the assumptions: nobody
should expect that RGB somehow magically makes on-chain BTC (I will
use this acronym to distinguish BTC-as-money from bitcoin-as-
blockchain or tech) more programmable or anyhow better: it is
impossible without softfork or a hardfork on _blockchain consensus_
level. What is possible is to add functionality on top of that; but
anything additional won’t work for BTC unless it is “lifted” into
that new layer. This is true with sidechains, this is true with
Lightning, this is for sure true with RGB. So any setups we are
analyzing must analyze such lifted BTC* in RGB as a value, and not
an on-chain. Next, most forms of contracts do not require a new
token, so I propose not to make setups more complex and start
discussing them without introducing a new tokens unless it is
really required.
Now, my setup to cover your case (or at least what I understood
from it) would be the following:
1. Assume we have some BTC lifted to RGB, which we will name BTC*.
(let’s leave the question on how to do that aside; it can be
discussed separately).
2. > Bob doesn't believe that there's a number which can be
multiplied by to produce 4. He's willing to pay a bounty for
proof that he's wrong.
This part I will take from your letter without changes, however
will skip the rest about production of some tokens etc, which
is unnecessary here.
(Please correct me if I am wrong in understanding what you wanted
to achieve and I will correct it - for instance I can't understand
why we need some Carol(s) at all).
To fulfill the described setup, Bob have to create a new RGB
contract (its **genesis**) featuring BTC* AND providing the
following conditions (in the contract **schema**, which is a part
of genesis):
1. The value of BTC* is preserved within the contract not attached
to any of UTXOs (it has become possible with RGB v0.10
introduction of “global state”)
2. BTC* can be reclaimed by any party providing a solution (in form
of RGB **state extension**) which is verified by AluVM. Alice,
if she have found the solution, now can **assign** that
previously “floating”/unowned BTC* to an UTXO she controls.
State extensions were introduced into RGB in late 2020 v0.4.
State extensions are different from a normal state transitions
by the fact that they do not have inputs referencing some
previously-owned (i.e. assigned to an UTXO) state, i.e. their
creation doesn’t require creation of a corresponding bitcoin
transaction spending some UTXOs with a state (as it is in case
of a state transitions).
3. To ensure uniqueness of the winner (i.e. prevent
“double-spending” of “free-floating”/unowned BTC* from the
contract global state) Alice is also required (by the contract
conditions defined by Bob in the contract schema) to post some
identifiable information into a mined bitcoin transaction
on-chain (NB: this is not the same as a witness transaction; it
can be any transaction not related to the contract UTXOs in any
way). The transaction must contain a pre-defined signal in a
form known only to the contract participants; for instance some
pre-defined random value stored in OP_RETURN, address, value,
witness, pay-to-contract tweak of some pre-defined pubkey - or
anywhere else. This can re-use a transaction which can be mined
anyway (like a payment that happens in parallel) and can even
avoid additional block space consumption if something like P2C
or tapret commitment is used (though this will require
a pre-knowledge of public keys at the moment of contract
creation). The contract script claims that only the first
party who had made such tx mined wins the game (if two txes are
mined in a block, they may be sorted by their txid or block
position). Because of AluVM, contracts can inspect on-chain
bitcoin state and find the signal.
That’s it! The structure of the contract would be genesis and that
thing called “state extension” - and nothing more. “Normal” RGB
flow (known to those who read about RGB before introduction of
state extensions) with state transitions and witness bitcoin
transactions would start only when Alice would like to spend that
BTC* or to peg out - and at that point of time an RGB state
transition will have to be created, and a corresponding bitcoin
transaction (called “witness transaction”) spending that Alice’s
UTXO, will have to be crafted, signed and mined.
Final notes:
============
Communication medium
--------------------
All communications between Alice and Bob happens wherever they
want - in IRC, mailing list, Nostr, telegram - or using
decentralized networks like LN (with [Storm] on top, which we
deliberately created for that purpose). It would be also possible
for Alice and Bob to use their RGB Nodes which will be
communicating through RGB RPC protocol - there is a lot of ways,
and RGB is fully abstracted from them.
Going fully off-chain
---------------------
The above design can be put fully off-chain if the group of players
may set up a n-of-n or n-of-m multiparty state channel (“channel
factory”).
Question of BTC*
----------------
Regarding BTC* creation, for now we do have at least two designs we
have developed over years:
1) for Lightning channels, which has the same level of
trustlessness as the pure BTC in LN;
2) on-chain "lifting" which is semi-trusted (trustless private
decentralized peg-in and semi-trusted federated peg-out
requiring user+federation multisig but no privacy/history
exposure thanks to zk; such on-chain lifting is still much
better than other alternatives with drivechains or federated
sidechains).
Last, but not least
-------------------
> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in multiparty protocols, as previously described on this
> list [1] by Ruben Somsen?
As far as I see, Ruben's letter was about different protocol, built
by Lightning Labs after they had studied (since they did plan to
implement) RGB - but they ended up with taking results of many years
of our research and did a successful fundraising of ~80m on it, even
"forgetting" to mention the original authors - until they were
ashamed by the community. Funny enough, even the original name of
their "protocol" was [CMYK].
I have no desire on commenting how they solved (and did they solve)
that - or any other - problem. I expect that they would again try
to take the solution I have described above and do another
fundraising with motto of transforming their product into “smart
contracts on Lightning” :)
Kind regards,
Maxim Orlovsky
CEO (Chief engineering officer)
@ LNP/BP Standards Association,
https://lnp-bp.org
Twitter: @lnp_bp
-----
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021559.html
[Storm]: https://github.com/Storm-WG
[CMYK]: [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-18 23:16 ` Dr Maxim Orlovsky
@ 2023-04-19 19:37 ` David A. Harding
2023-04-19 22:17 ` Dr Maxim Orlovsky
0 siblings, 1 reply; 7+ messages in thread
From: David A. Harding @ 2023-04-19 19:37 UTC (permalink / raw)
To: Dr Maxim Orlovsky; +Cc: Bitcoin Protocol Discussion
On 2023-04-18 13:16, Dr Maxim Orlovsky wrote:
> 1. Assume we have some BTC lifted to RGB, which we will name BTC*.
> (let’s leave the question on how to do that aside; it can be
> discussed separately).
Hi Maxim,
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.
- Xavier and Yasmin create an RGB contract that says any BTC deposited
into multi(2,x,y) can be used as BTC\*
- Bob acquires some of this BTC\*
- Bob offers his BTC\* to anyone who can provide x for (4 == 2 * x)
- Alice knows x = 2
- Alice asks Xavier and Yasmin to sign an onchain transaction
withdrawing Bob's BTC\*. She provides them proof that Bob offered his
BTC\* and that she knew the answer. The both sign the the
transaction.
In short, I think this capability of RGB allows easily creating
user-defined sidechains based on arbitrary scripts. This is similar to
what Elements allowed last I looked at it, although RGB makes the
process of creating new sidechains much smoother, reduces global state,
and allows sidechain tokens (including tokens like lifted BTC) to be
used with LN without sidechain-specific programming. That seems like a
significant advance to me.
What it doesn't provide is trustless contracting beyond the capabilities
of Bitcoin script. To be fair, when I looked at your documentation
again just now, I don't see it promising enhanced **trustless**
contracting---I see it only promising enhanced contracting, which I (and
perhaps others) seem to have interpreted as also being trustless.
I hope I've understood you correctly. Regardless, thank you for your
many detailed answers to my questions!
-Dave
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-19 19:37 ` David A. Harding
@ 2023-04-19 22:17 ` Dr Maxim Orlovsky
0 siblings, 0 replies; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-19 22:17 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
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
distinguished, otherwise the contract trust model can't be anyhow better
than a fixed centralized BTC* design you add to the equation as an
assumption:
> What it doesn't provide is trustless contracting beyond the
> capabilities of Bitcoin script.
However:
1. Contract x*2=4 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,
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
(which Peter Todd calls "proof of publication medium") can be
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
operate on both bitcoin blockchain (let's call it timechain) and the
new blockchain (we call the new blockchain "sigchain" or "sealchain",
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
plenty of smart contracts which do not need BTC/BTC* at all and can
operate on RGB even today - but which were impossible on bitcoin
blockchain or lightning before RGB (at least without heavily polluting
block space):
1. Bearer securities - corporate shares, bonds, options, futures etc.
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
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,
privacy-preserving way and with bitcoin, not requiring new/other
tokens. Arguably, this is the largest thing that happened to bitcoin
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,
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
(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=DtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-04-19 22:18 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-10 22:09 [bitcoin-dev] RGB protocol announcement Dr Maxim Orlovsky
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky
2023-04-19 19:37 ` David A. Harding
2023-04-19 22:17 ` Dr Maxim Orlovsky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox