David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-16 🗒️ Summary of this message: Dr. Orlovsky's ...

📅 Original date posted:2023-04-16
🗒️ Summary of this message: Dr. Orlovsky's RGB project aims to build a programmability layer for Bitcoin and Lightning, enabling assets beyond tokens, such as DAOs and decentralized identities. However, there are concerns about the security of non-publishable conditional statements in multiparty protocols.
📝 Original message: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