Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BBA34C002A for ; Sun, 16 Apr 2023 07:16:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 95B5060F21 for ; Sun, 16 Apr 2023 07:16:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 95B5060F21 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=b5saj7j1 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9v-sUufAOuP for ; Sun, 16 Apr 2023 07:16:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AD7F460F10 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by smtp3.osuosl.org (Postfix) with ESMTPS id AD7F460F10 for ; Sun, 16 Apr 2023 07:16:12 +0000 (UTC) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-94f32588c13so35767966b.2 for ; Sun, 16 Apr 2023 00:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681629371; x=1684221371; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VkyxM4Irq2Geejpg7N2F07tVxwKsafuu+ngQNzVa2NA=; b=b5saj7j1nbv3NRB+0s3yyO41z1h1Rx00l4h9WljvZ4FbfdD2b+ocfUkmm9LPj8SU0s jGzo0i2OwPTj8+aAlma5BXdA9Pv+l3wsWMn37zqQY/vauNNme9vB1Vroj/DcrInQ5BXI z3Ns4huQ6VW/23SwO806nl52hdCt7IG/7MM+OCpj0UNeiXXQhSBdQqLxm84yB7v2hM/h DRpcQ3LUD/+po8L8b9Zt2IYvRW98O74wdJaTqZFCXunGYL9o2itZWU+dxM5PCaDVecxk 23dXIVQCKKeFoJFZkHkfIeDn8luFeFS/lFYRWJ8YVbuq/V1778K4Dy35P/fJmIQV3eIs +f8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681629371; x=1684221371; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VkyxM4Irq2Geejpg7N2F07tVxwKsafuu+ngQNzVa2NA=; b=KWltlfcWFBS0uupGJWhJn1i37hlCkkXOoV4z3KpXsRVkhiO9RDVLPL42uSl+SqhsHq N4dsQzlNPKaqCoGMf6wzyksmXuaAOiG39HdkXhMf9/BQh+i7FzgUC0zYnD3c79nfHJ17 wZNaoJigdxF3HtXhibuELBRh6aWpHAwH6md1fdemTh4BxFyXHq39re+8eCxaDUorlYAB 52Z+9/yS0bbzrZJs/XQPOHvrsGR/nD//CvPhlhZFMjyvNzYp367luv38vGRTBrBqw6eu TYgxJOpqqJ3uOAeDIfZ8DqvLsvm/EYp11V1IwDJXGI+YEQ5mppP07aDWn6pEr2K3EGYd 3ioA== X-Gm-Message-State: AAQBX9e+sIsVx3OwBaDoSa5eHOs0Zf9mMRTML4oeRef8qJgITsbp1oPu ZaLekPYtcDBrbFwUSuSi6jzJVqFcgoMnAWWixTPx/jHZthRxKyNK X-Google-Smtp-Source: AKy350bA/RYWtz8dlnLyzHHA8XNKFMd7v492wUeaI8dZO/o7k9FgtR4/4tmABG+aRuVxAtmJpTz/6n51x8CdxlBl/MU= X-Received: by 2002:a50:9f88:0:b0:4fb:7e7a:ebf1 with SMTP id c8-20020a509f88000000b004fb7e7aebf1mr5482568edf.6.1681629370608; Sun, 16 Apr 2023 00:16:10 -0700 (PDT) MIME-Version: 1.0 References: <3089493b2f202e30af42a485efec3fd1@dtrt.org> In-Reply-To: <3089493b2f202e30af42a485efec3fd1@dtrt.org> From: Federico Tenga Date: Sun, 16 Apr 2023 09:15:58 +0200 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000047756c05f96ed99a" X-Mailman-Approved-At: Sun, 16 Apr 2023 08:20:43 +0000 Subject: Re: [bitcoin-dev] RGB protocol announcement X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2023 07:16:14 -0000 --00000000000047756c05f96ed99a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D=3D 4) to spend his RGB-based tokens. He publis= hes > 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 (=E2=80=9Chow to design a blockchain= today > > if we > > knew about client-side-validation/single-use-seals=E2=80=9D). This shou= ld 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/c402decc9ff5b557a9e3d542f74e2fd6e= d856742/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/0035= 40.html > [2] > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/0035= 49.html > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000047756c05f96ed99a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To add some context to the conversation, I would like to p= oint 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://githu= b.com/RGB-Tools/rgb-lightning-sample

On Sun, 16 Apr 2023 at 07:35, Davi= d A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Dr Orlovsky,

Thank you for writing about your interesting project.=C2=A0 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><= br>
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&quo= t;, see
https://github.com/RGB-WG/rgb-node/

> My goal with RGB was not just to enable assets on Lightning, but that<= br> > 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?=C2=A0 To give my own example of the problem:

- Bob doesn't believe that there's a number which can be multiplied= by 2
=C2=A0 =C2=A0to produce 4.=C2=A0 He's willing to pay a bounty for proof= that he's wrong
=C2=A0 =C2=A0but Bitcoin does not currently provide a multiplication opcode= , so he
=C2=A0 =C2=A0can't simply pay a script that says: "2 OP_MUL 4 OP_E= QUAL"

- Bob hears that RGB has turing-complete scripting, so he buys some
=C2=A0 =C2=A0random tokens that have an RGB contract which allows him to en= cumber
=C2=A0 =C2=A0them by any AlumVM script.=C2=A0 He then creates a Bitcoin tra= nsaction
=C2=A0 =C2=A0signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone kno= wing the
=C2=A0 =C2=A0solution to (x * 2 =3D=3D 4) to spend his RGB-based tokens.=C2= =A0 He publishes
=C2=A0 =C2=A0a PSBT for the transaction along with the RGB data needed to c= laim the
=C2=A0 =C2=A0tokens.

- Anyone on the network can now claim the BTC without knowing the
=C2=A0 =C2=A0solution, destroying the RGB-based tokens.

- If, instead, Bob hears that Mallory knows the solution, he could sign a
=C2=A0 =C2=A0PSBT with the default SH_ALL to her, but then Mallory could ta= ke the
=C2=A0 =C2=A0BTC without solving the problem, again destroying the RGB-base= d
=C2=A0 =C2=A0tokens.

- Or, in another case, Bob hears that Alice knows the solution, but he
=C2=A0 =C2=A0doesn't want to risk his tokens being destroyed, so he ref= uses to sign
=C2=A0 =C2=A0a transaction paying Alice until she provides him the answer.= =C2=A0 When
=C2=A0 =C2=A0Alice does provide him the answer, and he realizes it's so= simple, he
=C2=A0 =C2=A0changes his mind about paying her and doesn't sign his tra= nsaction to
=C2=A0 =C2=A0her.=C2=A0 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 perfec= t for
> the
> client-side-validated applications (=E2=80=9Chow to design a blockchai= n today
> if we
> knew about client-side-validation/single-use-seals=E2=80=9D). This sho= uld 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<= br> > 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?=C2=A0 While trying t= o
learn about RGB, I noticed that you don't have much completed
documentation.=C2=A0 Previous reviewers also mentioned this and I saw that<= br> 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.=C2=A0 For example, I can't find where it supports creating or parsing onions, which seems to be a fundamental requirement
for using LN.=C2=A0 In trying to figure out how it works, I also noticed th= at
I couldn't find either unit tests or integration tests---indeed several=
of your applications seem to almost entirely lack the string "test&quo= t;.
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.=C2=A0 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.=C2=A0 All I found was that a small amount of previous unit<= br> 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.=C2=A0 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.=C2=A0 E.g.= ,
they seemed to stop at the same point as this demo:
https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e= 2fd6ed856742/doc/demo-alpha.4/README.md

> Despite 4 years of active development, weekly community calls, talks o= n
> 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.=C2=A0 As far as I can tell, it doesn't do that yet, not even in a way that's accessible t= o a
power user such as myself.=C2=A0 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.=C2=A0 The payoff for that effort could be a huge change that affects how we use Bitcoin and LN for decades to come.=C2=A0 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.=C2=A0 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.linuxf= oundation.org/pipermail/lightning-dev/2022-April/003540.html
[2]
https://lists.linuxf= oundation.org/pipermail/lightning-dev/2022-April/003549.html
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000047756c05f96ed99a--