path: root/51/731a7cd8d036d92321477af5201e06a27b253b

Return-Path: <federicotenga@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BBA34C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Apr 2023 07:16:12 +0000 (UTC)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-94f32588c13so35767966b.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <JpC1PVaT1XunO5ZCcan4GkylS8cUadw8ueukJhEyfdFu2tzHa1CqcXT8vZDytu3ZEX9qPJ1pqG85NfqZ0cwGerHLXh3ZrUTXksxoPxuYyxA=@lnp-bp.org>
 <3089493b2f202e30af42a485efec3fd1@dtrt.org>
In-Reply-To: <3089493b2f202e30af42a485efec3fd1@dtrt.org>
From: Federico Tenga <federicotenga@gmail.com>
Date: Sun, 16 Apr 2023 09:15:58 +0200
Message-ID: <CAP=-fx4St32yzKozpxiC68kMqg3s4Hne8Psws_YmyB20v3Cn4Q@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
> > <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 =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 '\<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/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

<div dir=3D"ltr">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: =
<a href=3D"https://github.com/RGB-Tools/rgb-lightning-sample">https://githu=
b.com/RGB-Tools/rgb-lightning-sample</a> </div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 16 Apr 2023 at 07:35, Davi=
d A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dr Orlovsky,<br>
<br>
Thank you for writing about your interesting project.=C2=A0 Some replies<br=
>
inline below:<br>
<br>
On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:<br>
&gt; RGB v0.10 can be downloaded and installed as described on <br>
&gt; &lt;<a href=3D"https://rgb.tech" rel=3D"noreferrer" target=3D"_blank">=
https://rgb.tech</a>&gt;<br>
&gt; website, which also contains a number of user and developer guidelines=
.<br>
&gt; RGB source code can be found on &lt;<a href=3D"https://github.com/RGB-=
WG" rel=3D"noreferrer" target=3D"_blank">https://github.com/RGB-WG</a>&gt;<=
br>
<br>
FYI: the RGB-WG organization page links to a repository whose latest<br>
release is 0.9 and whose latest commit is titled, &quot;Release v.0.9.1&quo=
t;, see<br>
<a href=3D"https://github.com/RGB-WG/rgb-node/" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/RGB-WG/rgb-node/</a><br>
<br>
&gt; My goal with RGB was not just to enable assets on Lightning, but that<=
br>
&gt; of a much larger scope: to build a programmability layer for Bitcoin<b=
r>
&gt; and Lightning, which may unlock other cases than just tokens - DAOs,<b=
r>
&gt; decentralized identities and other things that bitcoin itself was <br>
&gt; lacking.<br>
<br>
Is there any documentation or discussion archives that address the<br>
problem of non-publishable conditional statements seemingly being <br>
insecure in<br>
multiparty protocols, as previously described on this list[1] by Ruben<br>
Somsen?=C2=A0 To give my own example of the problem:<br>
<br>
- Bob doesn&#39;t believe that there&#39;s a number which can be multiplied=
 by 2<br>
=C2=A0 =C2=A0to produce 4.=C2=A0 He&#39;s willing to pay a bounty for proof=
 that he&#39;s wrong<br>
=C2=A0 =C2=A0but Bitcoin does not currently provide a multiplication opcode=
, so he<br>
=C2=A0 =C2=A0can&#39;t simply pay a script that says: &quot;2 OP_MUL 4 OP_E=
QUAL&quot;<br>
<br>
- Bob hears that RGB has turing-complete scripting, so he buys some<br>
=C2=A0 =C2=A0random tokens that have an RGB contract which allows him to en=
cumber<br>
=C2=A0 =C2=A0them by any AlumVM script.=C2=A0 He then creates a Bitcoin tra=
nsaction<br>
=C2=A0 =C2=A0signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone kno=
wing the<br>
=C2=A0 =C2=A0solution to (x * 2 =3D=3D 4) to spend his RGB-based tokens.=C2=
=A0 He publishes<br>
=C2=A0 =C2=A0a PSBT for the transaction along with the RGB data needed to c=
laim the<br>
=C2=A0 =C2=A0tokens.<br>
<br>
- Anyone on the network can now claim the BTC without knowing the<br>
=C2=A0 =C2=A0solution, destroying the RGB-based tokens.<br>
<br>
- If, instead, Bob hears that Mallory knows the solution, he could sign <br=
>
a<br>
=C2=A0 =C2=A0PSBT with the default SH_ALL to her, but then Mallory could ta=
ke the<br>
=C2=A0 =C2=A0BTC without solving the problem, again destroying the RGB-base=
d<br>
=C2=A0 =C2=A0tokens.<br>
<br>
- Or, in another case, Bob hears that Alice knows the solution, but he<br>
=C2=A0 =C2=A0doesn&#39;t want to risk his tokens being destroyed, so he ref=
uses to sign<br>
=C2=A0 =C2=A0a transaction paying Alice until she provides him the answer.=
=C2=A0 When<br>
=C2=A0 =C2=A0Alice does provide him the answer, and he realizes it&#39;s so=
 simple, he<br>
=C2=A0 =C2=A0changes his mind about paying her and doesn&#39;t sign his tra=
nsaction to<br>
=C2=A0 =C2=A0her.=C2=A0 She has no recourse.<br>
<br>
It seems to me, based on my understanding of Somsen&#39;s original insight,=
<br>
that client-side validation by itself cannot enforce conditions in a<br>
trustless multiparty setting.<br>
<br>
I think that implies that it&#39;s only possible to enforce conditions in a=
<br>
consensus system (or in a trust-dependent system), which would have<br>
significant implications for the future direction of your work, as you<br>
wrote in your email:<br>
<br>
&gt; We&#39;re also working on the design of a layer 1 which will be perfec=
t for <br>
&gt; the<br>
&gt; client-side-validated applications (=E2=80=9Chow to design a blockchai=
n today <br>
&gt; if we<br>
&gt; knew about client-side-validation/single-use-seals=E2=80=9D). This sho=
uld be <br>
&gt; very<br>
&gt; compact (order of one signature per block) ultra-scalable <br>
&gt; (theoretically<br>
&gt; unlimited no of tx in a block) chain which can run systems like RGB - =
<br>
&gt; with<br>
&gt; Bitcoin UTXO set migrated into RGB [...]<br>
<br>
* * *<br>
<br>
Looking at other parts of your email:<br>
<br>
&gt; Nevertheless, in 2021 we were able to present both RGB powered with a<=
br>
&gt; Turing-complete virtual machine (AluVM) [2] and RGB had became <br>
&gt; operational on<br>
&gt; Lightning Network [3] using the LNP Node - a complete rust <br>
&gt; re-implementation of<br>
&gt; the Lightning protocol made by me at the Association [4].<br>
<br>
Could you clarify the status of these implementations?=C2=A0 While trying t=
o<br>
learn about RGB, I noticed that you don&#39;t have much completed<br>
documentation.=C2=A0 Previous reviewers also mentioned this and I saw that<=
br>
you suggested them to read the code or view your videos.<br>
<br>
When reading your code for your LN implementation (LNP), I noticed it<br>
seemed to be missing a lot of things present in other LN implementations<br=
>
I regularly review.=C2=A0 For example, I can&#39;t find where it supports<b=
r>
creating or parsing onions, which seems to be a fundamental requirement<br>
for using LN.=C2=A0 In trying to figure out how it works, I also noticed th=
at<br>
I couldn&#39;t find either unit tests or integration tests---indeed several=
<br>
of your applications seem to almost entirely lack the string &quot;test&quo=
t;.<br>
For example, here are LNP-node and RGB-node compared to the four LN<br>
implementations I regularly monitor:<br>
<br>
/tmp/rgb-node$ git grep -i &#39;\&lt;test\&gt;&#39; | wc -l<br>
7<br>
/tmp/lnp-node$ git grep -i &#39;\&lt;test\&gt;&#39; | wc -l<br>
4<br>
<br>
~/repos/rust-lightning$ git grep -i &#39;\&lt;test\&gt;&#39; | wc -l<br>
2008<br>
~/repos/cln$ git grep -i &#39;\&lt;test\&gt;&#39; | wc -l<br>
1459<br>
~/repos/lnd$ git grep -i &#39;\&lt;test\&gt;&#39; | wc -l<br>
3547<br>
~/repos/eclair$ git grep -i &#39;\&lt;test\&gt;&#39; | wc -l<br>
2576<br>
<br>
I realize those are all projects by larger teams than that which works<br>
on RGB, but a difference of three orders of magnitude is very surprising<br=
>
to me.=C2=A0 Do you have out-of-tree testing or am I missing something else=
?<br>
I did my best to earnestly search both your repository and your GitHub<br>
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<br>
testing were closed without referencing a resolution.<br>
<br>
As your replies to previous reviewers also mentioned that they should<br>
view your Youtube videos, I also tried that.=C2=A0 I focused on the ones<br=
>
discussing LNP, as LN is something I know fairly well, and I admit that<br>
I skimmed them quite fast, but I couldn&#39;t find any demos where you<br>
progressed beyond using LNP to open a channel with another node.=C2=A0 E.g.=
,<br>
they seemed to stop at the same point as this demo:<br>
<a href=3D"https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542=
f74e2fd6ed856742/doc/demo-alpha.4/README.md" rel=3D"noreferrer" target=3D"_=
blank">https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e=
2fd6ed856742/doc/demo-alpha.4/README.md</a><br>
<br>
&gt; Despite 4 years of active development, weekly community calls, talks o=
n<br>
&gt; all mainstream bitcoin-only evens and conferences, the awareness about=
 <br>
&gt; RGB<br>
&gt; in the bitcoin community is still very small<br>
<br>
My understanding of the basic goal of RGB from years ago was that it<br>
would allow ordinary users to define new assets on Bitcoin in a way that<br=
>
would allow those assets to be transferred over LN.=C2=A0 As far as I can<b=
r>
tell, it doesn&#39;t do that yet, not even in a way that&#39;s accessible t=
o a<br>
power user such as myself.=C2=A0 Even for that original goal, there are<br>
several problems outstanding---problems which will likely require<br>
significant research and experimentation to overcome, e.g.[2].<br>
<br>
Instead of tackling those problems and building upon existing wallet and<br=
>
LN libraries, I see an ambitious effort at reimplementation and massive<br>
scope creep.=C2=A0 The payoff for that effort could be a huge change that<b=
r>
affects how we use Bitcoin and LN for decades to come.=C2=A0 But it also<br=
>
seems possible that the ambition and scope creep may be preventing the<br>
project from currently serving many of the people who were most excited<br>
about it in the first place.=C2=A0 Awareness may be limited because the<br>
near-term benefits for most people who invest time in learning about RGB<br=
>
also seems limited.<br>
<br>
Thanks again for writing about your research for this mailing list,<br>
<br>
-Dave<br>
<br>
[1] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-A=
pril/003540.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2022-April/003540.html</a><br>
[2] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-A=
pril/003549.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2022-April/003549.html</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000047756c05f96ed99a--