Author: Federico Tenga 2023-04-16 07:15:58
Published on: 2023-04-16T07:15:58+00:00
The conversation starts with an introduction to an RGB lightning implementation based on LDK that can be checked out to have a better understanding of how RGB works on LN. The email exchange between David A. Harding, a member of the bitcoin-dev mailing list, and Dr Maxim Orlovsky discusses various aspects of RGB development. Dr Orlovsky explains that his goal with RGB is not just to enable assets on Lightning, but to build a programmability layer for Bitcoin and Lightning that may unlock other cases than just tokens - DAOs, decentralized identities, and other things that bitcoin itself was lacking. David A. Harding raises concerns related to non-publishable conditional statements being seemingly insecure in multiparty protocols, which was previously discussed on the list by Ruben Somsen. He gives an example where Bitcoin does not provide a multiplication opcode, so it is impossible to pay a script that says: "2 OP_MUL 4 OP_EQUAL". However, 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. Anyone on the network can now claim the BTC without knowing the solution, destroying the RGB-based tokens. It seems to him that client-side validation by itself cannot enforce conditions in a trustless multiparty setting.David also asks for clarification on the status of RGB implementations and expresses his surprise at their lack of unit tests or integration tests compared to other LN implementations. He also couldn't find any demos discussing LNP, even though there were videos that suggested viewing them. He believes that RGB's ambition and scope creep may prevent the project from serving many of the people who were most excited about it in the first place since the near-term benefits seem limited.
Updated on: 2023-06-16T17:18:12.717781+00:00