RGB protocol announcement

Summary:

In this email response to David, the author addresses several questions and comments related to their RGB protocol implementation. They clarify that the RGB Node is not a part of the current RGB release, and that the LNP implementation is "experimental" but no longer required for using RGB on Lightning Network. The author also notes that a lot of documentation has been written and is being written, including foundational crates with more docs than code itself, and lists several websites tracking RGB documentation. Regarding testing, the author explains that the RGB consensus-level and integration libraries have undergone significant rewrites in version 0.10, which led to outdated tests being thrown out. They note that while more testing could be done, the strict types system used in the project provides compilation-type verification of data serialization, deserialization, and semantic type systems, leading to actual code coverage exceeding 2/3 (>60%). The author also clarifies that the LNP Node repository is just a shell providing I/O, networking, and thread management, not requiring extensive testing, and that one should look into the actual LNP codebase implementing BOLT standards instead.The author responds to David's comment that they couldn't find any demos where RGB progressed beyond using LNP to open a channel with another node, providing links to more recent demos of node operations. The author also clarifies that there are teams working on the first UI apps using RGB, but that this is not a task for a non-profit protocol-level research organization.Finally, the author explains that much of their work has been focused on solving hidden problems related to the original goal of allowing ordinary users to define new assets on Bitcoin in a way that would allow those assets to be transferred over LN, which required development of complex protocols and solving compatibility issues with existing lightning implementations.The author has been an active contributor to a project from 2019-2022, focusing primarily on privacy-related improvements. Other developments included a dedicated virtual machine and rich data type system with features including formal verification and compiler-time safety guarantees. The developed type system allows for proving that all data types used in consensus code do not mutate between releases.The author emphasizes the importance of proper design over shipping earlier, especially in consensus-level protocols where softforks are not possible. The letter addresses misconceptions and misinterpretations being spread around and clarifies these issues. The author has shared this letter on the bitcoin-dev mail list but not on Twitter to avoid wasting time. Relevant links to the project's contributors and the developed type system have been provided.

Updated on: 2023-06-16T17:21:47.540545+00:00