Federico Tenga [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-16 🗒️ Summary of this message: RGB Lightning ...

📅 Original date posted:2023-04-16
🗒️ Summary of this message: RGB Lightning implementation based on LDK available at https://github.com/RGB-Tools/rgb-lightning-sample. RGB aims to build a programmability layer for Bitcoin and Lightning.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230416/b611f172/attachment-0001.html>;