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 > > > > website, which also contains a number of user and developer guidelines. > > RGB source code can be found on > > 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 '\' | wc -l > 7 > /tmp/lnp-node$ git grep -i '\' | wc -l > 4 > > ~/repos/rust-lightning$ git grep -i '\' | wc -l > 2008 > ~/repos/cln$ git grep -i '\' | wc -l > 1459 > ~/repos/lnd$ git grep -i '\' | wc -l > 3547 > ~/repos/eclair$ git grep -i '\' | 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 >