Bitcoin has changed the way we think about money and not just that. But how to improve a technology already disruptive per se to make it even more revolutionary?
This is explained by Giacomo Zucco, founder of BHB Network in presenting the new project he is working on, namely the RGB protocol.
Zucco had already mentioned the project a few months ago, interviewed by Cryptonomist during the MJAC conference in London, but now we are going to elaborate on it.
On July 5th, in fact, Zucco officially presented the RBG protocol during the Lisbon conference.
What exactly is the RGB protocol? What does it mean for Bitcoin?
It is an attempt to coordinate and stimulate the most serious and credible Bitcoin community around the theme of Bitcoin-based digital assets, a theme that in the past has been more than anything else the prerogative of not serious areas, both at the level of technological foundations and economic foundations, with some trips in the Bitcoin area that have had little or no success. It is a proposal to arrive at a standard and a series of best practices on these issues, starting from the relaunch of the old idea of Colored Coin, this time, however, focusing on the native integration of Lightning Network and the Client-Side-Validation architecture, conceived by Peter Todd. The protocol also consists of a series of specifications that substantiate this proposal and Rust libraries that implement it.
How was the idea born? Who are you working with on this project?
The project is open to the whole Bitcoin community and, just in these days, after the presentation at the Building on Bitcoin conference, we are receiving a lot of feedback from active developers on Lightning Network, as well as others on other projects related to Bitcoin-based assets. , like Counterparty and Confidential Assets, also to try to maximize synergies, convergences and interoperability. The project, however, was born,and is currently coordinated by the non-profit BHB Network, and it is sponsored by Blockchainlab Switzerland SAGL and some of its customers. The original idea came from one of these customers, Digital Identity, who had commissioned Blockchainlab for advice almost a year ago. From a first brainstorm between the developers of Blockchainlab and some independent Resident Experts of BHB Network, I’m referring in particular to Peter Todd and Riccardo Casatta. The idea started to take shape. The main influence that has prevailed on the general architecture is that of Peter Todd, since we will follow his approach, known as “ClientSideValidation”, and considering that he himself is developing in these months a further extension called Proofmarshal. But also the advent of Lightning Network has had a fundamental impact, with many of the main developers who have given suggestions and contributions, especially Christian Decker. The type of innovative commitment we use, called “pay-to-contract”, has been included above all with the help of Leonardo Comandini, from Eternity Wall / Open Timestamps.
Can you add some information regarding the team?
To date, a large part of the design revision work, of concretization of specifications and development of the actual code is done by the very talented and very young Alekos Filini, our developer made available full time by Blockchainlab Switzerland on the project, assisted by other developers Blockchainlab as Isidoro Ghezzi and Gianluca Mazza. However, we have already received contributions from other subjects, including the Italian startups Inbitcoin and Chainside and many international developers. For now I am acting as a testimonial for the project, as well as being its initial promoter and influencing high-level choices.
Finally, the GitHub repository is maintained by Alekos, who will take care to keep order in the project, which being open will have to manage stimuli, suggestions and contributions among the most disparate.
What is the main goal? Supplant Ethereum?
The main objective is to offer to the possible use cases a sensible standard, which is scalable as much as possible and respectful of privacy, which exploits as much as possible the strengths of the Bitcoin protocol already existing, but at the same time avoid to weigh it down or jeopardize it, and get rid of the Bitcoin constraints when they are not needed.
We want to offer a standard that can guarantee the typical features sought by the market in Bitcoin-based assets (transparency, independence from the issuer, openness and social scalability, etc.), avoiding as much as possible the disadvantages of previous experiments: reduced privacy, reduced scalability, reduced interoperability, incompatibility with the new evolutions of Bitcoin.
A goal is also to experiment with new architectures, such as Client Side Validation and Proofmarshal, and investigate the potential and limitations of Lightning Network, of which RGB inherits many advantages and also many challenges, such as the receipt of assets by users offline. In our opinion, Ethereum and ERC20 are very bad standards, which will be supplanted regardless of our efforts, but we would like to be able to provide a good alternative to indicate.
Many developers and Bitcoin Maximalists have expressed their support for the project. What is the community feedback?
For now, I have to say excellent. The skepticism of the Bitcoin community to experiments of this kind, especially in its “maximalist” component of which I feel part, also derives from some big problems that during the creation of RGB we tried to honestly tackle and mitigate, if not even solve . Unlike previous attempts, the design of RGB does not create a conflict of interest between the scarce resources of the Bitcoin nodes (blockspace, bandwidth) and the resources required by the assets to be issued and transported. The relationship between RGB and Bitcoin is in my opinion more balanced, harmonious and “respectful” than it was with previous experiments in this field. I also believe that I have had some merit in illustrating the usefulness and the opportunity of an effort like this on a philosophical level. In Lisbon, we had the enthusiastic endorsement of many important names, at least on the idea, on the general plant and on the goals. Now the goal is to reach as much consensus as possible on the specifications and, starting from those, completely rewrite the code with production quality, while gathering all the appropriate feedback.
What’s the timing of the realization? On which use cases do you want to concentrate on?
From the first brainstormings of last year, up to the first Proof of Concept in Python developed internally at Blockchainlab, several months have passed. But now the big picture is definitely defined and further disruptions are unlikely. We envisage a work of about two months to finalize the formalization and revision of the specifications at the community level, then at least a semester to move from the implementation in Rust to the actual integration in some wallet at the production level. The cases of use that interest us most are those, quite realistic already today, of the “Digital collectibles” (see for example the phenomenon of “RarePepes” on Counterparty), and those still a bit ‘science fiction of the “smart right” automatic independent of the issuer and the regulation (see for example the token for the future DAO of the Bisq project). Then there are interesting token cases, so to speak, semi-regulated, which can be useful as a representation of fiat currency and therefore as a bridge for the adoption of Bitcoin (see for example Tether’s ‘’dollar’’).