* Re: [bitcoin-dev] RGB protocol announcement
2023-04-16 5:34 ` David A. Harding
@ 2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky
2 siblings, 0 replies; 7+ messages in thread
From: Federico Tenga @ 2023-04-16 7:15 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8479 bytes --]
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 == 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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 10354 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
@ 2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky
2 siblings, 0 replies; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-18 0:47 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi David,
Thank you for taking time on doing analysis and writing comments.
I will address all small questions in this reply -- with a follow-up
e-mail dedicated to the technical question from your letter
regarding the problem of "on-publishable conditional statements seemingly
being insecure in multiparty protocols", which requires longer write-up.
> 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/
Thank you for spotting; we hadn't updated the readme. Now its fixed.
> > 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?
The status of LNP implementation is "experimental": it is an instrument
for testing new protocols in the scope of the Lightning network, and
its main feature is in having lightweight and modular architecture.
LNP implementation is not anymore required for using RGB on LN - as
Federico already mentioned in his reply, Bitfinex team was able to
independently integrate RGB with existing LDK codebase [1] (I even
didn't know about that before they announced), and there is a WIP on
integrating RGB through CLN extensions. So the question of LNP node
readiness/completeness is unrelated to the question of RGB readiness,
features or technical properties; in my previous e-mail I just had
pointed out that at some (past) point in time we had to work on LN
re-implementation due to some restrictions we had back those days --
like with pay-to-contract commitments which were impossible to
implement in the existing nodes due to architecture limitations --
but with the change to taproot-based commitments in late 2021-
early 2022 this is not true anymore.
> 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.
A lot of documentation was written and is being written. For instance,
if you look at the foundational crates we have in RGB, they are
well documented, containing more docs than the code itself, like in
<https://github.com/LNP-BP/client_side_validation/blob/master/single_use_seals/src/lib.rs>
Also, we have a number of websites tracking the RGB docs, listed in
<https://rgb.tech/docs/> and <https://rgb.tech/learn/> - literally
dozens of them. So your information is outdated.
Of course, much more need to be written - but again, for a small team
of community & self-fundend non-profit with the budget comparable to
a coffee shop. I think we are doing all what we can. If community
needs more docs -- it is welcome to provide more funding or hands in
writing them.
> 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.
It is there, literally for years, where it should be - in P2P protocol,
BOLT4, as directory and file names suggest:
<https://github.com/LNP-WG/lnp-core/blob/master/lnp2p/src/bolt/bolt4.rs>
It is based on our other library which provides encryption:
<https://docs.rs/internet2/0.9.0/internet2/presentation/sphinx/index.html>
> 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
RGB Node is not a part of the current RGB release -- starting from
v0.10 RGB do not require a background service. The node is still useful
in server-side environments - but 100% of mobile and most of desktop
users and wallet devs would never need to touch it; thus the update
of the node to v0.10 will come later. Anyway, there is no reason of
doing its extensive test coverage since it its role to be a wrapper
around RGB libraries (existing in other repositories) which contain
100% of RGB consensus and applied business logic. Node just manages
threads and file I/O - not the stuff which is test-covered first of
all (and even for that task it uses others of our libraries with a
like io-react, used in other high-load projects. (BTW pls pay
attention to how such libs are documented:
<https://docs.rs/io-reactor/0.1.2/reactor/>).
The real RGB code is here, as it is clearly stated in the Github:
* consensus-level
- <github.com/RGB-WG/rgb-core>
- <github.com/BP-WG/bp-core>
- <github.com/LNP-BP/client_side_validation>
* integration libraries - <github.com/RGB-WG/rgb-wallet>
With the update to v0.10 a lot of code was changed, so most of tests
got outdated and were thrown out. Yes, we need more time and
effort to re-do them -- but even taking that into the account,
the core of RGB is covered to much greater extent than the estimations
you have provided:
* client-side-validation library - 80%:
<https://app.codecov.io/gh/LNP-BP/client_side_validation>
* RGB Core - ~25% (due to significant re-write in v0.10)
<https://app.codecov.io/gh/RGB-WG/rgb-core>
Finally, the most of code coverage happens due to the used
strict types system [4], which does compilation-type verification
of all data serialization, deserialization and semantic type system.
I.e. with its taken into account, the actual code coverage exceeds
2/3 (>60%). I provide more explanations at the end of the letter.
> /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
Well, that's a strange way to estimate the code coverage by counting
lines with the word "test". I usually use code coverage reports, like
those coming from codecov.com -- since neither count of unit tests nor
code lines in them are a valid metric to see how the code is
test-covered.
Unlike all those implementations, the node repository doesn't contain
any lightning network business logic or protocols - it is just a "shell"
providing I/O, networking and thread management, not requiring much
testing. Instead, one should look into the actual LNP codebase
implementing BOLT standards, which is in
<https://github.com/LNP-BP/lnp-core>. And as one might see from test
coverage reports [2] it has 40% of all code covered in tests - which
is not huge, yes, but (see next reply)...
> 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?
... as I pointed above, there is no "three orders of magnitude" difference
if the comparison is done correctly. Of course mainstream implementation
developed for more than 5 years, with millions invested by large companies/
non-profits and full teams of devs will have more test coverage than
an implementation created at my own personal expense - and I do not
understand what is surprising here :) I wrote about this implementation
to attract more interest from the community devs who may be interested
in joining to work/use an independent lightning re-implementation with
more open architecture allowing much larger protocol-level customizations
than any other mainstream implementation out there.
> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that.
I had never replied to previous _reviewers_ like that. For instance, the
protocol was reviewed by Peter Todd and Federico Tenga, as well as by
other devs from the community, and I am sure they can confirm that the
communications were complete and I was providing all the required answers
and comments. If you are talking about Ruben Somsen, he was never
introduced to me as a reviewer, nor wrote to me anything other than
several sarcastic tweets -- and I rather see him as an internet troll,
who, notwithstanding verbal communications and explanations I
had provided him over phone call, continues to spread miss-information
positioning himself as "RGB expert" -- while still demonstrating absence
of desire of reading any recent updates we had even when provided links.
> I focused on the ones
> discussing LNP, as LN is something I know fairly well,
But this discussion is an offtopic to RGB and this letter. I am fine to
have it, but let's move it to a separate thread.
> 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
The current LNP Node version is v0.9, so v0.4-alpha is extremely outdated,
as well a doc there. For sure the doc needs an update. These are more
recent demos of node operations, with a remote CLN node as of end of 2021:
* https://youtu.be/DoNfKLLjzsY
* https://youtu.be/L6JlIQXbl6Y
> 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.
I do not know how to compare the power of users, but, for instance it
was successfully demonstrated by an independent Bitfinex team using BDK
and LDK last month on the stage of Lightning Tuscany Summit. Of course
there yet no fancy UI all around, but absence of UI says nothing about
technology or its readiness. In fact, several teams are working on the
first UI apps using RGB, so this thing will change - and it is not a
task for a non-profit protocol-level research organization, but rather
for commercial ventures.
> 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.
Sorry for not meeting your expectations about how I should use my time,
funds and funds of those who support such developments :)
The real part of the story is that 80% of the time we were working
on solving the original scope you pointed out. It just appeared that
there were much more hidden stones (than was expected back in 2018)
in doing the idea of "assets over Lightning":
* the original single-use-seals didn't worked for the world of multiple
assets which may co-exists, which required development of a set of
quite complex protocols (still being probably most complex part
of RGB);
* the original pay-to-contract commitment scheme did work badly on
practice, being poorly inter-operable with existing lightning
implementations (which took a year of work on LNP node in total,
as I mentioned above) and leading to hard problems in wallet
integration and compatibility with all existing frameworks. We were
solving that problem until Taproot had arrived - and then we switched
to Taproot-based commitment scheme. It took another half of year
to update the whole code base - but the reward was compatibility
with BDK, LDK and other existing tools in the ecosystem, so your
comment on "Instead of tackling those problems and building upon
existing wallet and LN libraries" is not valid;
* as a part of the above, I had to significantly contribute to
taproot implementation and maintenance of rust-bitcoin project,
being the most active project contributor during the course of
2019-2022 [3] (="building upon existing wallet libraries);
* a lot of time was spent on privacy-related improvements, since none
of the original authors nor sponsors had seen any value about putting
"colored coins on lightning" without worriyng about the privacy;
and only after that comes some "fancy stuff", like doing a dedicated
virtual machine and rich data type system -- which primary features
were not "Turing completeness" but ability of formal verification and
compiler-time safety guarantees. For instance, the developed type
system [4] allows not just to "compile" any rust data type into a
smart contract, but also to prove that all data types used in
consensus code do not mutate between releases. If bitcoin had that
type system, there would be no "unnoticed" hardforks or risks of them
in a future -- and I think not implementing such system in doing a
new consensus protocol would be a poor decision. And the last, but
not least, I do not want to be in such situation
<https://twitter.com/fiatjaf/status/1647976362374844416?s=61&t=H4U6Q30N4eanvS4GjyAt4g>
preferring to spend a year more on a proper design instead of
"shipping earlier". What is acceptable for networking protocols
can't be acceptable for consensus-level protocols, which, unlike
even blockchain consensus can't have softforks.
----
Overall, I am quite negatively impressed with the amount of
misinterpretations and estimates which are simply wrong - and I know
that they are being floated around working like fake news.
Unfortunately writing answers to such claims takes a lot of time -
and takes it from doing other stuff like writing docs, tests or
integrations. I understand that this letter will be read by many,
thus I did address some of most common misconceptions. I am doing
that on bitcoin-dev mail list, but not elsewhere, since if I were
doing that on Twitter I would never have time for anything else.
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021558.html
[2]: https://app.codecov.io/gh/LNP-WG/lnp-core
[3]: https://github.com/rust-bitcoin/rust-bitcoin/graphs/contributors?from=2019-01-11&to=2022-04-11&type=c
[4]: https://www.strict-types.org
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
@ 2023-04-18 23:16 ` Dr Maxim Orlovsky
2023-04-19 19:37 ` David A. Harding
2 siblings, 1 reply; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-18 23:16 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi Harding,
This is the continuation from my previous e-mail [1] addressing the
largest and last unanswered question from your reply:
> To give my own example of the problem <… description follows …>
I am not entirely understand your argument or question, even though
I have spent a lot of time trying to crack it. For me it seems that
this is due to different paradigms we are thinking in. Client-side-
validation and work on RGB had required me to dramatically change
the way I see distributed systems, bitcoin and other “blockchains”
and multi-party contracts, thus this may have caused inability to
speak in the same terms. For me, the setup you are describing
doesn’t make sense at all: there is no reason of doing things with
RGB that way. I.e, you are suggesting invalid setup - and then
prove that it is not working :).
I will try first to explain why I think the reasoning you are
putting into the argument is invalid in the assumptions: nobody
should expect that RGB somehow magically makes on-chain BTC (I will
use this acronym to distinguish BTC-as-money from bitcoin-as-
blockchain or tech) more programmable or anyhow better: it is
impossible without softfork or a hardfork on _blockchain consensus_
level. What is possible is to add functionality on top of that; but
anything additional won’t work for BTC unless it is “lifted” into
that new layer. This is true with sidechains, this is true with
Lightning, this is for sure true with RGB. So any setups we are
analyzing must analyze such lifted BTC* in RGB as a value, and not
an on-chain. Next, most forms of contracts do not require a new
token, so I propose not to make setups more complex and start
discussing them without introducing a new tokens unless it is
really required.
Now, my setup to cover your case (or at least what I understood
from it) would be the following:
1. Assume we have some BTC lifted to RGB, which we will name BTC*.
(let’s leave the question on how to do that aside; it can be
discussed separately).
2. > Bob doesn't believe that there's a number which can be
multiplied by to produce 4. He's willing to pay a bounty for
proof that he's wrong.
This part I will take from your letter without changes, however
will skip the rest about production of some tokens etc, which
is unnecessary here.
(Please correct me if I am wrong in understanding what you wanted
to achieve and I will correct it - for instance I can't understand
why we need some Carol(s) at all).
To fulfill the described setup, Bob have to create a new RGB
contract (its **genesis**) featuring BTC* AND providing the
following conditions (in the contract **schema**, which is a part
of genesis):
1. The value of BTC* is preserved within the contract not attached
to any of UTXOs (it has become possible with RGB v0.10
introduction of “global state”)
2. BTC* can be reclaimed by any party providing a solution (in form
of RGB **state extension**) which is verified by AluVM. Alice,
if she have found the solution, now can **assign** that
previously “floating”/unowned BTC* to an UTXO she controls.
State extensions were introduced into RGB in late 2020 v0.4.
State extensions are different from a normal state transitions
by the fact that they do not have inputs referencing some
previously-owned (i.e. assigned to an UTXO) state, i.e. their
creation doesn’t require creation of a corresponding bitcoin
transaction spending some UTXOs with a state (as it is in case
of a state transitions).
3. To ensure uniqueness of the winner (i.e. prevent
“double-spending” of “free-floating”/unowned BTC* from the
contract global state) Alice is also required (by the contract
conditions defined by Bob in the contract schema) to post some
identifiable information into a mined bitcoin transaction
on-chain (NB: this is not the same as a witness transaction; it
can be any transaction not related to the contract UTXOs in any
way). The transaction must contain a pre-defined signal in a
form known only to the contract participants; for instance some
pre-defined random value stored in OP_RETURN, address, value,
witness, pay-to-contract tweak of some pre-defined pubkey - or
anywhere else. This can re-use a transaction which can be mined
anyway (like a payment that happens in parallel) and can even
avoid additional block space consumption if something like P2C
or tapret commitment is used (though this will require
a pre-knowledge of public keys at the moment of contract
creation). The contract script claims that only the first
party who had made such tx mined wins the game (if two txes are
mined in a block, they may be sorted by their txid or block
position). Because of AluVM, contracts can inspect on-chain
bitcoin state and find the signal.
That’s it! The structure of the contract would be genesis and that
thing called “state extension” - and nothing more. “Normal” RGB
flow (known to those who read about RGB before introduction of
state extensions) with state transitions and witness bitcoin
transactions would start only when Alice would like to spend that
BTC* or to peg out - and at that point of time an RGB state
transition will have to be created, and a corresponding bitcoin
transaction (called “witness transaction”) spending that Alice’s
UTXO, will have to be crafted, signed and mined.
Final notes:
============
Communication medium
--------------------
All communications between Alice and Bob happens wherever they
want - in IRC, mailing list, Nostr, telegram - or using
decentralized networks like LN (with [Storm] on top, which we
deliberately created for that purpose). It would be also possible
for Alice and Bob to use their RGB Nodes which will be
communicating through RGB RPC protocol - there is a lot of ways,
and RGB is fully abstracted from them.
Going fully off-chain
---------------------
The above design can be put fully off-chain if the group of players
may set up a n-of-n or n-of-m multiparty state channel (“channel
factory”).
Question of BTC*
----------------
Regarding BTC* creation, for now we do have at least two designs we
have developed over years:
1) for Lightning channels, which has the same level of
trustlessness as the pure BTC in LN;
2) on-chain "lifting" which is semi-trusted (trustless private
decentralized peg-in and semi-trusted federated peg-out
requiring user+federation multisig but no privacy/history
exposure thanks to zk; such on-chain lifting is still much
better than other alternatives with drivechains or federated
sidechains).
Last, but not least
-------------------
> 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?
As far as I see, Ruben's letter was about different protocol, built
by Lightning Labs after they had studied (since they did plan to
implement) RGB - but they ended up with taking results of many years
of our research and did a successful fundraising of ~80m on it, even
"forgetting" to mention the original authors - until they were
ashamed by the community. Funny enough, even the original name of
their "protocol" was [CMYK].
I have no desire on commenting how they solved (and did they solve)
that - or any other - problem. I expect that they would again try
to take the solution I have described above and do another
fundraising with motto of transforming their product into “smart
contracts on Lightning” :)
Kind regards,
Maxim Orlovsky
CEO (Chief engineering officer)
@ LNP/BP Standards Association,
https://lnp-bp.org
Twitter: @lnp_bp
-----
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021559.html
[Storm]: https://github.com/Storm-WG
[CMYK]: [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-18 23:16 ` Dr Maxim Orlovsky
@ 2023-04-19 19:37 ` David A. Harding
2023-04-19 22:17 ` Dr Maxim Orlovsky
0 siblings, 1 reply; 7+ messages in thread
From: David A. Harding @ 2023-04-19 19:37 UTC (permalink / raw)
To: Dr Maxim Orlovsky; +Cc: Bitcoin Protocol Discussion
On 2023-04-18 13:16, Dr Maxim Orlovsky wrote:
> 1. Assume we have some BTC lifted to RGB, which we will name BTC*.
> (let’s leave the question on how to do that aside; it can be
> discussed separately).
Hi Maxim,
Ok, I think I understand you, but I'd like to try rephrasing what you
wrote in a very brief format to see if you agree that it's correct and
in the hopes that it might help other Bitcoin/LN developers understand.
- Xavier and Yasmin create an RGB contract that says any BTC deposited
into multi(2,x,y) can be used as BTC\*
- Bob acquires some of this BTC\*
- Bob offers his BTC\* to anyone who can provide x for (4 == 2 * x)
- Alice knows x = 2
- Alice asks Xavier and Yasmin to sign an onchain transaction
withdrawing Bob's BTC\*. She provides them proof that Bob offered his
BTC\* and that she knew the answer. The both sign the the
transaction.
In short, I think this capability of RGB allows easily creating
user-defined sidechains based on arbitrary scripts. This is similar to
what Elements allowed last I looked at it, although RGB makes the
process of creating new sidechains much smoother, reduces global state,
and allows sidechain tokens (including tokens like lifted BTC) to be
used with LN without sidechain-specific programming. That seems like a
significant advance to me.
What it doesn't provide is trustless contracting beyond the capabilities
of Bitcoin script. To be fair, when I looked at your documentation
again just now, I don't see it promising enhanced **trustless**
contracting---I see it only promising enhanced contracting, which I (and
perhaps others) seem to have interpreted as also being trustless.
I hope I've understood you correctly. Regardless, thank you for your
many detailed answers to my questions!
-Dave
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] RGB protocol announcement
2023-04-19 19:37 ` David A. Harding
@ 2023-04-19 22:17 ` Dr Maxim Orlovsky
0 siblings, 0 replies; 7+ messages in thread
From: Dr Maxim Orlovsky @ 2023-04-19 22:17 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
Hi David,
> Ok, I think I understand you, but I'd like to try rephrasing what you
> wrote in a very brief format to see if you agree that it's correct and
> in the hopes that it might help other Bitcoin/LN developers understand.
In your description you mix together question of how BTC* can be issued
and how the contract settlement happens. However, they must be
distinguished, otherwise the contract trust model can't be anyhow better
than a fixed centralized BTC* design you add to the equation as an
assumption:
> What it doesn't provide is trustless contracting beyond the
> capabilities of Bitcoin script.
However:
1. Contract x*2=4 settlement is fully trustless.
2. BTC* contract settlement may vary.
One may argue that there is no way of getting BTC* in a trustless way,
but this is not true:
1. We may have a trustless BTC* in lightning channels (including
multiparty channels with many participants).
2. It also depends on how you define the value of the original BTC.
If BTC is a coin existing in bitcoin blockchain, than yes - you
can't have a fully trustless BTC* for on-chain operations. But if
you define BTC as a digital scarcity strictly inheriting existing
UTXO set from bitcoin blockchain, but which may exist elsewhere
than bitcoin blockchain, you may have a 100% trustless BTC*.
What can be a case for (2)? As I told in my first letter, with RGB
we do not need the existing heavy-duty bitcoin blockchain at all.
We still need a layer 1 settlement for our single-use-seals, but it may
have a very different design comparing to existing bitcoin blockchain.
At LNP/BP Standards Association we are working on such design for the
last 3 years, and have quite a lot of progress in this direction. The
design we have for the layer 1 needed for client-side-validation
(which Peter Todd calls "proof of publication medium") can be
represented as a single signature + pubkey per block, scaling up to
theoretically unlimited number of transactions. There are still some
problems we have to solve, but overall the direction seems realistic.
So, if/once we have a new blockchain, RGB (or its successor) can
operate on both bitcoin blockchain (let's call it timechain) and the
new blockchain (we call the new blockchain "sigchain" or "sealchain",
depending on the design model - we currently have 2 of them). Than, BTC
can be 100% trustlessly lifted from the timechain into RGB - and than
operate on top of the sigchain. In this model no pegout would be ever
needed, and the last point of trust gets removed.
> In short, I think this capability of RGB allows easily creating
> user-defined sidechains based on arbitrary scripts.
True, but RGB capabilities are even much larger than that. There is a
plenty of smart contracts which do not need BTC/BTC* at all and can
operate on RGB even today - but which were impossible on bitcoin
blockchain or lightning before RGB (at least without heavily polluting
block space):
1. Bearer securities - corporate shares, bonds, options, futures etc.
They will be 100% confidential and censorship-resistant + scalable
b/c of Lightning network. Yes, you still trust the issuer (like with
corporate shares), but the the secondary market is much improved.
2. Bearer ownership rights ("NFTs done in the right way"), again
private, scalable, not polluting blockchain. For instance, I would
like to have all books & songs as a bought to be present in this
format. This also opens options for creators to earn commissions not
just from an initial sale, but also from secondary market.
3. Digital collateral-based stable coins (in terms of their purchasing
power and not necessary linked to any fiat).
4. Digital identity, where RGB and single-use-seals make key revocation
a global event. Without this it is impossible to prove that a given
key was or was not revoked at certain date.
5. Decentralized naming systems - like ENS, but much better because
no ethereum is required :)
6. Provable historical event logs: opentimestamps doesn't allow
proving that there is no alternative commitments. With RGB it is
possible to build event logs which has 100% trustless provable
properties that no alternative history of the events does exist.
For instance, if a doctor gives a prediction that a baby will be
a boy and not a girl, it is impossible to witness the case with
OpenTimeStamp (the doctor can make 2 OTSes for both outcomes),
while with RGB it can be proven that no alternative commitment was
created.
7. Liquidity pools, DEXes, AMM and other fancy stuff on Lightning,
which we call "BiFi" (Bitcoin finance). One may listen to the talk
on the last Bitcoin Amsterdam conference where I have presented
that concept [1]. It requires more than just RGB - also some
improvements to the Lightning network and protocols like Storm
as a decentralized (tokenless!) data layer - but all of that is
WIP at LNP/BP Standards Association with many parts already being
released in a test versions (another reason why LNP Node is
important - a topic we were discussing two e-mails ago).
Thus we say that RGB allows everything what can be done with existing
"blockchain smart contracts" - but in much more scalable,
privacy-preserving way and with bitcoin, not requiring new/other
tokens. Arguably, this is the largest thing that happened to bitcoin
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,
especially when gossip traffic and liquidity limitations are taken
into account).
The time will show where all these assumptions about the potential of
sigchain and #BiFi are correct. Meanwhile, we at LNP/BP Standards
Association continue our work on advancing bitcoin protocol and
lightning network protocols - without whining about any soft- or hard-
forks :). Of course, we, as a non-profit, need support - so all bitcoin
hodlers are welcome to join the very few organizations and individuals
already supporting our efforts [2], making all this future possible
(you can contact us via "ukolova [at] lnp-bp.org").
At the end, I'd like t, thank you for the detailed analysis and great
write-up on RGB in the latest Bitcoin Optech Newsletter. It explains
RGB in more simple words than I was was able to!
Kind regards,
Maxim Orlovsky
LNP/BP Standards Association
GitHub: https://github.com/LNP-BP
Twitter: @lnp_bp
[1]: https://www.youtube.com/watch?v=DtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/
^ permalink raw reply [flat|nested] 7+ messages in thread